help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: audio check?


From: Jim Langston
Subject: Re: audio check?
Date: Wed, 26 Sep 2007 12:47:21 -0400
User-agent: Thunderbird 1.5.0.8 (X11/20061204)

With Sun/Studio, when the stream is read, initially it is empty, because
it is empty, underflow() is called to fill it, this is different than Linux/GNU.
After that, underflow() is called when a character is needed or is empty.

The algorithm in the underflow method getting overridden by Octave
is going into an infinite loop because it does an fgetc and an ungetc
but never reports an eof.

I think that a setg must be called in order to correctly handle the underflow.

Does anyone know who has written the overflow method an can give
me a pointer? I created a test case which initially looked just like the
current method, and indeed, went into an infinite loop, changing it to
do a setg:

streambuf::int_type FILE_buffer::underflow()
{
  if (fptr_)
  {
    int_type c = fgetc (fptr_);
 
    if (c != traits_type::eof ())
    {
        printf( "int_type %c\n", c );
        buffer_[0] = c;
        setg( &buffer_[0], &buffer_[0], &buffer_[1] );
    }
 
    return (streambuf::int_type) c;
}
else
return traits_type::eof ();
}

took care of the infinite loop and allowed the read to get the data
it needs. What I need to do, and haven't looked at yet, is correctly
handling the buffer which is built for the read (ie. u.buf)


Jim

////////////////////////////




Jim Langston wrote:
I think I have created a test case which is doing something similar
to what Octave is doing with the reading of the .wav file. My only
problem is that it will read a character and not loop. Anyone want
to enhance or shoot down?

Jim

//////////////////////////////

Jim Langston wrote:
Hi all,

Pursuing further - in oct-stream.cc

is.read (u.buf, sizeof (typename octave_type_traits<READ_T>::val_type));

The size is 1

This call is made and never returns, what is happening is that underflow is getting
called and goes into a continuous loop calling the logic in underflow_common.
underflow_common resides in c-file-ptr-stream.cc


on Linux, the read gets called with a size of 1 as well, and returns after the read, underflow
and, hence, underflow_common are never called.

It would be helpful for me if someone could break the logic down and create a smaller program
doing the same thing, ie. create a streambuf, open a .wav file, read into the buffer with size one
and return, while overriding the underflow method.

Any help, thoughts, ideas ?

Jim

////////////////////////////////////////////////////


Jim Langston wrote:
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
  

_______________________________________________ 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
  

_______________________________________________ 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
  

_______________________________________________ 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]