[slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
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. Can anyone comment on why it appears that in normal operation, only about 256Kb of SB1 buffer memory is being used? I am basing that statement on the status messages that can be seen from the SB: 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 -- nico nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=20863 ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
On 2/10/06, nico [EMAIL PROTECTED] wrote: Don't want to flog a dead horse here... but just stumbled across thehardware 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 ofraw WAV audio @ 150Kb/sec. This would be more than adequate inbuffering 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 ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
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. -- radish radish's Profile: http://forums.slimdevices.com/member.php?userid=77 View this thread: http://forums.slimdevices.com/showthread.php?t=20863 ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
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 nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=20863 ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
nico: Sounds like some good detective work. Would you mind updating the wiki to reflect this? Just so that others don't get confused. Thanks. --- nico [EMAIL PROTECTED] wrote: 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 nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=20863 ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss __ Find your next car at http://autos.yahoo.ca ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
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. -- ceejay ceejay's Profile: http://forums.slimdevices.com/member.php?userid=148 View this thread: http://forums.slimdevices.com/showthread.php?t=20863 ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
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 nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=20863 ___ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Re: Audio dropouts during Search Music - Possible to increase buffering?
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.
--
treble
treble's Profile: http://forums.slimdevices.com/member.php?userid=2797
View this thread: http://forums.slimdevices.com/showthread.php?t=20863
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
