PDA

View Full Version : Audio dropouts during "Search Music" - Possible to increase buffering?



nico
2006-02-07, 19:26
version: 6.2.1 - 5194 - solaris - EN - iso-8859-1

I get a repeatable audio dropout each time I use Search Music. I've looked into the cause and believe it's due to slimserver not servicing the audio stream while it's busy doing the query.

Here's my analysis: When I enable d_slimproto I see messages like "fullness: 228868 (99%)" during normal playback. From this I assume my SB1 has approx 256Kb buffer memory. I am transcoding FLAC->WAV on the server, thus am streaming WAV audio to the SB1 at a rate of about 150Kb/sec. If the SB1 has 256Kb buffer memory, this corresponds to about 1.7 seconds of audio play before the audio buffer is drained. When I use Search Music, it appears the server becomes busy for at least couple of seconds, despite running on a fairly powerful machine (dual Xeon 3GHz, 2Gb memory, etc). However note that I have a fairly large music collection (32k tracks). During the brief time it takes for the search to complete, I note the buffer fullness display I have enabled on the SB drops from 99% to 0%, and a dropout occurs.

It seems my choices are limited. I know I can choose to stream MP3 to the SB rather than WAV, but I would prefer not to. Also, buying an SB3 would be an advantage (more buffer memory and onboard FLAC decoder). The long term solution is to refactor the search code (SQLLite query engine?) in slimserver to avoid starving the audio stream. However in the meantime, is there any way to increase the amount of audio stream buffering in the system (either in sw or hw)?

Thanks in advance for any thoughts or ideas.
Nick

treble
2006-02-07, 23:14
I got the same thing with skipping to the next song in a random mix. But my PC is not a dual Xeon by far ('fairly powered' you call it!?). For me it only occured when I was using MySQL. When I switched back to SQLite the dropouts disappeared. Unexpected, since I thought MySQL would be quicker. I have about 13K tracks.

At one time I had a 'cache' indicator in my SoftSqueeze, like percent full. Now I can't remember how I got it to show.

ceejay
2006-02-08, 01:02
How to reduce dropouts?

1 - (simple but expensive) - upgrade to an SB3, as you already noted

2 - (a bit of a pain) - switch to using high bit rate MP3s... it is claimed that 320kbit MP3 is pretty indistinguishable from lossless, though this of course depends on the rest of your kit, and ears! You could try a few, though.

3 - (worth a try) - switch to mySQL... treble's experience in the last post is interesting, other people have reported improved performance. Can't hurt to try it out.

4 - wait - longer term, the code is being separated into different components which should mean that searching time doesn't interfere so much with important stuff like playing music

5 - tweak the OS - I note you are running solaris, can you ensure that slimserver has one of the CPUs to itself?

Ceejay.

nico
2006-02-08, 01:18
Thanks for all those suggestions. So it seems like extending the level of buffering (somehow) is not an option? (short of SB3 purchase of course). That's good to know, I won't pursue that avenue any more.

Probably my next move is to try MySQL (I run this on my machine anyway for other applications). Whether it gets rid of the gap I guess will all depend on whether or not the code blocks when it submits the SQL query to the server (hopefully it's async/non-blocking!), and/or, how long it takes the server to process the query (relative to SQLLite).

Failing that, I guess I will switch to a high bitrate MP3 as you suggested, at least until the search components are separated.

Regarding comment #5, about tweaking the OS, I have already spent a little time optimizing this already. There is a write-up here: http://forums.slimdevices.com/showthread.php?t=20865 Unfortunately, despite these scheduler tweaks, I could not get rid of the droupouts resulting from search queries.

Cheers,
Nico

nico
2006-02-10, 10:28
Don't want to flog a dead horse here... but just stumbled across the hardware spec for the SB1:

http://wiki.slimdevices.com/index.cgi?HardwareComparison

It says the SB1 has 8Mb of buffer RAM... This would equate to approx 47s of raw CD-quality audio (ie WAV format = 176,400 bytes/sec). This would be more than adequate in buffering a delay on the server of a couple of seconds.

Can anyone comment on why it appears that in normal operation, only about 256Kb of audio buffer memory is being used? I am basing that statement on the status messages that can be seen from the slimserver when d_slimproto is enabled:

"fullness: 228868 (99%)"

If the buffer is 99% full at 228,868 bytes, this is nothing even close to the 8Mb of memory the device is claimed to have.

Anyone have any insights into this?

TIA,
Nico

radish
2006-02-10, 13:43
Note: This is all complete guess work :)


"fullness: 228868 (99%)"

You're assuming that number is in bytes, let's suppose it's frames, where a frame is 4 bytes (2 bytes per channel, 2 channels). That gives us a fullness of 915472 bytes.

You're also assuming "8Mb" is 8 megabytes, I think it's much more likely to be 8 megabits, or 1 megabyte.

915472 / (1024 * 1024) = 87%

I'm guessing the missing memory (13k or so?) is used for things other than buffer.

Ben Sandee
2006-02-10, 13:45
On 2/10/06, nico <nico.230xwb (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> Don't want to flog a dead horse here... but just stumbled across the
> hardware spec for the SB1:
>
> http://wiki.slimdevices.com/index.cgi?HardwareComparison
>
> It says the SB1 has 8Mb of buffer RAM... This equates to almost 60s of
> raw WAV audio @ 150Kb/sec. This would be more than adequate in
> buffering a delay on the server of a couple of seconds.


8 megabits. Little b. 1 megabyte. Big b. WAV audio is 150KB/sec or
~1100Kb/s. So the full buffer is only enough for 6-8 seconds of
uncompressed audio.

Ben

nico
2006-02-10, 19:39
Cool. I did try the 8 megabit == 1 megabyte calc before and also got the 6-8 seconds theoretical value you quoted. But *empirically*, the results seems to show that < 2s is buffered, which agrees more with the implication that only about 256 Kbytes are being buffered.

On my platform (UNIX) I can suspend and resume the slimserver.pl process at will to conduct tests. If playback is proceding normally, watching the buffer fullness display on the SB1 & the output from d_slimproto, I see the buffer is 99-100% ("228868" - whatever units of measure that is in). Then I suspend the slimserver process. In <2s the fullness display drops to 0% and the audio stops. This isn't close to the 6-8 seconds you'd expect. 2s @ 150Kbytes/sec == approx 300Kbytes, which is close to the number displayed (228868).

Digging around a bit further I found this:

http://wiki.slimdevices.com/index.cgi?SB1Hardware

This account of the SB1 hardware claims a "2Mb high-speed buffer". This may be more like the truth. 2Mb = 256KB (262,144 bytes exactly) which corresponds to exactly 1.49s of 44.1KHz/16-bit stereo PCM audio.

Thus the mystery is finally solved. The number displayed in d_proto's fullness output does appear to be bytes. Working backwards from "228,868 == 98%", the implied buffer size is around 233,539 bytes. This is in line with the 2Mb buffer spec. It would appear that approx 28KB of buffer memory is used for other things.

Thanks to all who contributed to this thread.

nico
2006-02-10, 19:44
Final note:

I switched to using the MySQL back end, and this completely solved the dropout problem. Now I can do complex searches without any interruption to full-quality WAV audio streams.

Cheers,
Nico