[vorbis-dev] ogg123 sampling rate problems

[Kenneth Arnold]

On Wed, Jan 24, 2001 at 10:17:50PM +1100, Michael Smith wrote:
> At 10:15 PM 1/23/01 -0600, you wrote:
> >I just used ogg123 to play back a file encoded from a 22.5 KHz WAV, and it
> >played twice too fast.  Looking at the source, it seems that the sampling
> rate
> >and number of channels are hard-coded into it.  What´s the best way of fixing
> >this?  I quickly hacked together something that closes and reopens the
> devices
> >before each file (diff attached).  Is there a better solution?
> 
> The 'right' solution here is to open the audio device(s) only once the
> relevent parameters are known, and then ONLY reopen it if those change (so,
> if you're playing multiple files with the same sampling rate, etc, you
> don't close the device between files. 
> 
> I don't have the time right now to dig into ogg123 (that part of the code
> is a bit messy, as I recall), but if you send a patch to do this, I'll
> commit it - the patch you attached ends up opening/closing multiple times
> even for a single file. If you don't do this, I'll try and hack something
> in later in the week.

I'm on it (would have been done already if I hadn't caught the flu and
yet have exams at the same time). I have a few ideas of my own about
libao<>ogg123 too.

> Under some circumstances you might want to do so, though (the obvious one
> is file output, but ogg123 gets this wrong for multiple files anyway - I
> haven't checked, but I think it'll just overwrite the file).
> 
> Really, the best thing to do is to rewrite much of the libao<->ogg123
> interface (by making libao do a lot more, and/or more flexibly, than it
> does now, and then making ogg123 use the new interfaces), and fix little
> things like this in the process. I don't think anyone really wants to do
> that, though. I might take a stab at it next weekend, if I'm not too busy. 

What are your ideas? I still have a patch or two from Stan to commit
(as you can tell I've been quite busy lately); if Stan could do a
quick check of which of his changes have and haven't been
committed... Then get him CVS commit rights.

Ken, lazy and very over-busy ogg123 author and sortof-maintainer's
TODO:

 * Fix that messy and GPL-wrong copyright header at the top
 * Rework libao
 * Rewrite HTTP streaming (need to know how to do on non-Unix)
 * Make buffering more flexible (perhaps semaphores are good after
   all...)
 * Add frontend interfaces
 * Internationalization (gettext)
 * Clean up a few messes
 * Continuous cycle, random or nonrandom mode
 * Ctrl-C to skip to next song (probably taken care of in frontend
   changes)
 * Overall cleanups
 * A few architecture changes (e.g. a 'stream' structure)
 * Increase overall spiffiness

In the HTTP streaming dept, I tried using callbacks ... just for
normal (local file) access for the moment. Basically my test
modification was:

callbacks.read_func = fread;
callbacks.seek_func = fseek;
callbacks.close_func = fclose;
callbacks.tell_func = ftell;

And I changed ov_open to ov_open_callbacks. It works okay, but delays
for a long time before starting to play; strace shows it reading 0
bytes from the file several hundred thousand times (I'm not counting!)
then finally starting the play. gdb shows that this is all in
ov_open_callbacks. Why would it be doing this? Of course the code is
the best documentation but I'm busy and have to go to bed now.

-- 
Kenneth Arnold <ken at arnoldnet.net> / kcarnold / Linux user #180115
http://arnoldnet.net/~kcarnold/



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010124/f473546c/part.obj