I'm getting drop outs on high quality audio streaming (above 96kb/s) on the smarttop - vanilla maverick image - ethernet or wifi connected, mplayer or Rhythmbox. On investigation using mplayer from a terminal the cache empties and does not refill sufficiently until paused.
My broadband connection easily supports this with my ordinary pcs.
Any ideas appreciated before I start digging?

example streams:
http://89.16.185.174:8000/stream
http://75.69.53.115:8004/

On the smartbook, disabling pulseaudio (which is an ugly, not supported hack) helped me to play high quality audio, even 192kHz audiophile music files. On the smarttop this did not work: if I disabled pulseaudio, then I got no sound on the headphones output.

_________________
CzP
http://czanik.blogs.balabit.com/

I've tried it with and without pulseaudio and it works both ways. Agree on pa though.
The problem appears to be data throughput related. I've tried streams from 32k to 320k. Up to 96k it is fine and reliable. The drop outs start at 128k but are intermittent. At 320k - see the examples posted - it's every 60 to 90 secs.

I've been using mpg123 built with neon optimisations for some time now. All issues with streaming of up to 256Kbps streams is usually solved for me through using a 2MB buffer (-b 2048). It takes noting that I have not had many issues with the smrttop (wired) just the smartbook, due to wifi interferences I've been getting from my router (notable outside of sound streaming too).

On completely different hardware, Intel Quad Core, 2 GB RAM, wired 6 mbit ADSL I get that too with http://89.16.185.174:8000/stream
mplayer says:
Looks like it's a problem with the server.
Looking at the Netspeed applet in my GNOME panel, it seems the server stops sending data sometimes. Increasing the mplayer cache with -cache to 4MB it seems fairly stable. It's been playing now for 5 minutes without dropouts in the audio, although I can see data still stops flowing sometimes, but then picks up ~5 seconds later. Larger cache seems to fix this.

Could maybe be an incompatibility/bug between the TCP/IP stacks of the server and Linux kernel, since this seems to only happen with Linux?

What's the server running?

It may actually be a problem with the wireless card in the Efika MX - not so much hardware, but the poor quality of drivers. Unfortunately Ralink wireless is well developed just really flakey on any kernel version.

If you can be sure that the server is not simply waiting on the Efika to send some kind of ACK, I would assume it's the Efika.

_________________
Matt Sealey

Well it looks like everyone was right on this.
The smarttop will play high def files from USB sticks and SDD with no problem. I used a 32/192 file and although mplayer automaticaly down sampled to 16/96 it played fine. More importantly for me 16/44.1 and 16/48 wavs play all day without a hitch.

When playing streams ajusting the buffers really does help but ulimately the dreaded cache not filling message appears at some point.

The problem is that the smarttop is chewing through bits quicker than it gets them! The playback speed is running 2.4% high. And that's from local files as well streams.
To check This should be concert pitch note A. It's not. Reduce to -f429 and a true A is heard.

Another check is with mplayer the track playing time is misreported - 4 minutes actually takes around 3m 54s

Final check and (imperfect) solution is to play streams with the -speed option.
mplayer -speed 0.976 somestreamname.

Most of the players have some form of speed option e.g. mpg123 uses --pitch (use -0.024)

The speed ajust allows 320k streams to play totally reliably - 5 hours is my longest test so far.

This is still not bit perfect audio of course but that may be one for the iMX53!

@curlybrain: Interesting. Thank you for your testing.

mpg123-1.13.3 with NEON
it played a 3'17'' file with only 3'13''

_________________
acrux _at_ linuxmail _dot_ org

That's quite interesting. Does anyone have any ideas on what could be causing this?

As far as I know, streaming audio will always - at some point - need to re-synchronize because the clocks of the server and client aren't 100% identical.
But this issue that you describe is obviously more grave than that; I'd expect differences in clock speed to be more in the line of <0.1%.

Have you tried using an external USB sound card with the SmartTop/Smartbook? If the hardware is sending bits too fast, I guess this might cause drop-outs in this case as well, if the external sound card is expecting 44.1kHz and getting ~45.2kHz.

By the way, just off the top of my head, the 2.4% figure sounds like it's a 1000/1024 "bytes per kilobyte"-ish issue. Could the software somehow be dividing with 1024 to get from Hz to kHz, instead of 1000?

Confirmation of 2.4% thanks

USB DAC works fine on streams with no drop outs.

Just to be clear I think the Smarttop is a brilliant machine with no real competition. Why?

Comes with case and power supply
Runs cool all day
Very low power consumption
Built in wifi
Totally silent - that is totally.
RGB LED indicator invaluable when headless
12v power input - use batteries
Boots in about 40s
Rock solid linux with 512MB RAM
Can use USB and SD storage
Has the SGTL5000 DAC

This last one was the surprise for me. The spec looks average but the sound is anything but. It has that left/right, front/back, and (rare) up/down sound stage that is seldom heard. Why? I don't know, but it could be true 16 bit input and who ever tuned the filters is a definite music lover. This is the reason I've invested some time testing this.

On your 1024 theory the maths is attractive but I think it more likely to be a clocking issue though as you can see from the news there will probably be a Linaro for that....

Keen to hear idaes in the mean time.

Just in case this sounds too good - I bought this retail and have no connection to Genesi, Freescale et al.

It could possibly be a rounding error, a place to look if you aren't afraid to get dirty, is the gitorious kernel tree, in arch/arm/mach-mx5/mx51_efikamx_audio.c; We are going to look at it this coming week, and hopefully push out a 2.6.31 kernel with a few different bug fixes, but don't quote me on that, as plans can and often do change. We definitely appreciate the fact that you looked in to this issue and gives us a quicker pinpoint.

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer

Steev -that'll be it. Shows clock as 12.2880 MHz. Codec is is set for 12MHz via pll. 12 x 1.024 = 12.288. Haven't tested it but looks likely?

If you like I can rebuild a kernel and you can test and let me know if it fixes the issue for you? Shoot me an email at steev@genesi-usa.com and I'll send it off.

_________________
Steev Klimaszewski, Genesi USA Inc.
Senior Software Engineer