[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: bug in arts
From:       Dan Stone <dan () headzofstate ! com>
Date:       2002-07-22 17:28:37
[Download RAW message or body]

> > So, you can't know the size of the buffer (pcm here) at the time of the
> > function call, unless there's something I'm missing...
>
> Hm, seems I missed something here. I automatically assumed that the pcm
> buffer had to be allocated outside the ogg library and of course then the
> length is known. I still assume this, so the code in gsldatahandle-vorbis.c
> would probably need to be changed to allocate a buffer for pcm first, and
> pass a pointer/length to ov_read_float.
>

Well, here's the thing...the only difference in ov_read_float() between 1.0rc3 
and 1.0 final is the addition of that function argument, and a single line in 
the function itself that uses it.  Here's a quick comparison:

1.0rc3:
long ov_read_float(OggVorbis_File *vf,float ***pcm_channels,int *bitstream) {
[some code snipped here]
	float **pcm;
	long samples=vorbis_synthesis_pcmout(&vf->vd,&pcm);
	if(samples){
		if(pcm_channels)*pcm_channels=pcm;
		vorbis_synthesis_read(&vf->vd,samples);
[and so on]

1.0 final:
long ov_read_float(OggVorbis_File *vf,float ***pcm_channels,int length,int 
*bitstream){
[same code snipped here]
	float **pcm;
	long samples=vorbis_synthesis_pcmout(&vf->vd,&pcm);
	if(samples){
		if(pcm_channels)*pcm_channels=pcm;
		if(samples>length)samples=length;
		vorbis_synthesis_read(&vf->vd,samples);
[and so on]

So, all that the new parameter is used for is to truncate 'samples' if it gets 
larger than a specified length -- something it didn't used to do.  Perhaps 
this length value is simply to allow undersampling or something, since its 
setting has nothing to do with pcm_channels?  *shrug*

~D.A. Stone

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]