Premature end of track for ogg format - fix?

[amb]

All my music on the Phatbox are in ogg format.  I experience sporadic cases of playback ending prematurely at the end of a song and skipping to the next song (there is no apparent pattern to this, most times it works fine).  Searching the forums revealed that this is a known problem.  Has anyone found a fix?

If not, I might attempt to dig into this.  I have a ARM cross-compile environment setup on my Linux PC, and could attempt to build the ogg vorbis libs and a player program executable.  If I go this route, does anyone know if the Phatbox kernel provides the standard Linux ALSA or OSS audio interface?  Or does it do something proprietary?

[Paul]

I have the same problem with my AAC files.  

[amb]

Paul, that's interesting.  If AAC files exhbit the same issue, then perhaps the problem isn't with the oggplay program itself.  Maybe it's a more generic issue that affects multiple formats?  Has anyone experienced this problem with other audio file types?

I did a bit of poking around by doing "strings" on the various player executables.  It would appear that the audio interface is OSS.  However, things don't look as straightforward as I'd imagined.  There is a /tmp/phatsock mechanism that apparently is used for some sort of IPC between the player programs and phatd (which looks like some sort of overall control process).  I guess that the player program passes some file tag info via this socket to phatd and this is somehow passed back to the HU for display purposes.  I don't know the data format used in this IPC mechanism, or whether the actual audio data is also fed through this conduit (i.e., whether the player program writes the audio data to /dev/dsp directly, or if it's passed on to phatd and handled there).  There also seems to be some sort of heartbeat-check in the phatd that would detect whether the player program had stopped unexpectedly.  One thing is now clear, and that is the player programs are developed to be tightly integrated into a Phatbox-specific scheme and not at all generic.  One cannot take, for example, a standard ogg player like ogg123, cross-compile it for ARM, rename it, sign it and expect it to work on the Phatbox.  It would take a fair amount of reverse- and forward-engineering, and I don't think I have the time to take this on.

BTW, while looking at the "51d" executable I found this humorous string in it:
"Hey!  Don't peek at my strings!"
[smiley=evil.gif]

At any rate, there are two ogg player programs: oggplay-la and oggplay-ha.  Does anyone know what's the difference between the two?  When would one be used rather than the other?  Searching here and on the web in general didn't yield anything useful.

[S80_UK]

Hi,

To answer the quesion about oggplay-la and oggplay-ha...

As I understand things, Ogg requires relatively more processing than some other codecs (I think it uses some floating point math).  So there are two decoders provided, one for lower bit-rate (oggplay-la) and one for higher bitrates (oggplay-ha).  My guess is that the lower bit-rate decoder is more "accurate", while the higher bit-rate decoder sacrifices accuracy for speed.  The underlying problem is that the processor in the Phatbox doesn't really have enough speed to support the Ogg codec fully.

Les.

[A543]

I've noticed that some of my startup sounds (MP3s) get about quarter to a half a second cut off at the end. I haven't noticed (or listened) for a pattern.

[judb]

Hi,

To answer the quesion about oggplay-la and oggplay-ha...

As I understand things, Ogg requires relatively more processing than some other codecs (I think it uses some floating point math).  So there are two decoders provided, one for lower bit-rate (oggplay-la) and one for higher bitrates (oggplay-ha).  My guess is that the lower bit-rate decoder is more "accurate", while the higher bit-rae decoder sacrifices accuracy for speed.  The underlying problem is that the processor in the Phatbox doesn't really have enough speed to support the Ogg codec fully.

Les.

Well, I think you have that backwards.. LA stands for Low Accuracy.. and HA stands for High Accuracy if I recall correctly.  So if you have lower bitrate files the HA decoder path plays them as it can stay within the CPU resources available, and if the bitrate is over a certian amount (160kbps I think) it goes to the low accuracy decoder which allows for more CPU cycles for the increased bit rate, but it still doesnt let you exceed about 225kbps if I recall correctly.


As for the ogg decoder, I don't know if they use OSS or whatever exactly.. but its my understanding they just dump the raw PCM audio after decoding to a /dev device that sends the pcm signal out to the DAC.

[S80_UK]

Hi judb,

I am sure you are right about -ha and -la.  To be honest I didn't check.  I was going from memory, and correlated the h and l with the bit rate for some reason.

Les.

[amb]

As I understand things, Ogg requires relatively more processing than some other codecs (I think it uses some floating point math).

I thought I read that the Phatnoise ogg players are based on Tremor, which is a fixed-point implementation...  Even so, the processing overhead is probably still very high.

Thanks for the explanations about the oggplay-la and oggplay-ha differences.  That just puts yet another nail on the coffin as far as me trying to do any hacking in this area.  It's getting too complicated.

Back to the subject of premature stoppage of playback near the end of songs, does anyone have any insight about the cause of that?

[judb]

Yes Tremor is the ARM decoder code tree that I was mentioning.. they built in two decoder paths into the tremor code and you can compile either one.  Phatnoise did both and sends songs with a specific bit rate or lower to the HA decoder build and any files over that go to the LA decoder..

And yes OGG is a floating point format.. they have to convert it to some crazy big interger format to do the decoding on ARM.. thats what tremor does instead of just a port of a ogg decoder tree.