|
From: | Jim Langston |
Subject: | Re: audio check? |
Date: | Fri, 14 Sep 2007 15:47:42 -0400 |
User-agent: | Thunderbird 1.5.0.8 (X11/20061204) |
Hi John,
Maybe you can give me a pointer, on the audio read error I've been having, I think I have it isolated down, it looks like it is in the underflow_common method and in particular the ungetc function. On Solaris, in the manpage: The ungetc() function pushes the byte specified by c (con- verted to an unsigned char) back onto the input stream pointed to by stream. The pushed-back bytes will be returned by subsequent reads on that stream in the reverse order of their pushing. A successful intervening call (with the stream pointed to by stream) to a file-positioning function ( fseek(3C), fsetpos(3C) or rewind(3C)) discards any pushed-back bytes for the stream. The external storage corresponding to the stream is unchanged. Four bytes of push-back are guaranteed. If ungetc() is called too many times on the same stream without an inter- vening read or file-positioning operation on that stream, the operation may fail. If the value of c equals that of the macro EOF, the opera- tion fails and the input stream is unchanged. A successful call to ungetc() clears the end-of-file indica- tor for the stream. The value of the file-position indicator for the stream after reading or discarding all pushed-back bytes will be the same as it was before the bytes were pushed back. The file-position indicator is decremented by each successful call to ungetc(); if its value was 0 before a call, its value is indeterminate after the call. Whereas w/ Fedora, from manpage: ungetc() pushes c back to stream, cast to unsigned char, where it is available for subsequent read operations. Pushed-back characters will be returned in reverse order; only one pushback is guaranteed. Calls to the functions described here can be mixed with each other and with calls to other input functions from the stdio library for the same input stream. Does anything with the extra work that the function on the Solaris side is doing going to keep the logic from completing correctly? Jim //////////////////// Jim Langston wrote: John W. Eaton wrote:On 6-Sep-2007, Jim Langston wrote: | Isolating down a little the old fashion way | | In oct-stream.cc | | printf("Getting ready to read\n") ; | is.read (u.buf, sizeof (typename | octave_type_traits<READ_T>::val_type)); | printf("Done Reading\n") ; | | This method never returns | | | octave:1> A = [1:10; 1:10]/10; | octave:2> wavwrite("a.wav", A); | octave:3> [B, samples_per_sec, bits_per_sample] = wavread("a.wav"); | Getting ready to read | ^C^CPress Control-C again to abort. | ^Cpanic: Interrupt -- stopping myself... | attempting to save variables to `octave-core'... | save to `octave-core' complete OK, but which call to fread in wavread is hanging? That should be fairly easy to determine as wavread is a .m file. It would be helpful to isolate this to a single call to fread rather than a call to wavread. Also, since it seems you are the only one who can trigger this problem, I think you are going to have to narrow it down to something very specific, like "fread is called and it attempts to read the following data and it fails to return because it is looping here, because ...". Also, perhaps this should be on the bug list?I'm working with the thought that all problems I encounter are mine since Octave has not been compiled and run under this env. (OpenSolaris, Sun Studio 12 compilers) - any pointers are great as I dig them out. I changed wavread.m to include printf's around the fread's, I get: octave:1> [B, samples_per_sec, bits_per_sample] = wavread("a.wav"); Getting ready to read ^C^CPress Control-C again to abort. ^Cpanic: Interrupt -- stopping myself... Opening File Opened File - OK: 5 First fread RIFF/WAVE signature attempting to save variables to `octave-core'... save to `octave-core' complete I'm not getting past the first fread encountered in the wavread.m file Debugging output shows the call to iostream, and then calls to c_file_ptr_buf and in particular, the underflow method. I'm not sure what is triggering this, but the bump value is always false and the value of c never varies from 82. My initial thought is that the stream buffer is not getting read and cleaned out. wavread.m snippet ...... printf("Opening File\n"); # open file for binary reading [fid, msg] = fopen (filename, "rb"); if (fid < 0) error ("wavread: %s", msg); endif # # printf("Opened File - OK: %d\n", fid); ## check for RIFF/WAVE header printf ("First fread RIFF/WAVE signature\n"); ck_id = char (fread (fid, 4))'; printf ("First fread - OK - RIFF/WAVE signature\n"); fseek (fid, 4, SEEK_CUR); printf ("Second fread RIFF/WAVE signature\n"); wave_id = char (fread (fid, 4))'; if (ck_id != "RIFF" || wave_id != "WAVE") fclose (fid); error ("wavread: file contains no RIFF/WAVE signature"); endif .....jwe _______________________________________________ Help-octave mailing list address@hidden https://www.cae.wisc.edu/mailman/listinfo/help-octave -- ///////////////////////////////////////////// Jim Langston Sun Microsystems, Inc. (877) 854-5583 (AccessLine) AIM: jl9594 address@hidden |
[Prev in Thread] | Current Thread | [Next in Thread] |