[vorbis-dev] ogg123 sampling rate problems

[Michael Smith]

>> 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.

Having found out that I get a three-day weekend, I found some time. So ogg123 now deals sensibly with inputs of differing sample rates/channels. There's a lot of other stuff (as you list later...) that needs doing too, but this was kinda annoying.
>> 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.

My ideas aren't too concrete at the moment, but end up involving rewriting most of libao (though hopefully not involving TOO many changes to the api). Basically, at the moment libao isn't very useful for anything more complex than ogg123, but it'd be nice to have something that was.

This mostly involves creating much more complex interfaces between everything (though simpler programs needn't use the extra complexity). 

For example, the libao core should ask the plugins what endianness/etc they accept. Then, auto-conversion should happen inside the libao core. However, external apps should also be able to find out what the endianness of choice is, so as to avoid extra byteswapping, if unneeded. 

Similarly, both applications and the core need much more in-depth info about the plugins' buffering (whether that's internal buffering, or buffering at the hardware layer) - we need additional interfaces right through there. I doubt I'll get around to any of this stuff for ages, anyway.

>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.

That's very strange... ov_open() basically does precisely this (sets callbacks, then calls ov_open_callbacks(). Ah.. Actually, there's one crucial difference - fseek is replaced by a (trivial) wrapper. The vorbisfile seek_func allows 64 bit seeks. The wrapper simply casts the 64 bit arg to an int, and calls fseek(), but the wrapper IS needed. I can imagine this could cause weirdness like this.

For HTTP streaming, of course, you should just have the seek_func return -1.

Michael

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.