Setup:
– firefly latest nightly on a NSLU, deunderclocked.
– Debian OpenSlug-LE with ogg tremor patch in the transcoder (manual patch).
– Serving ca. 4k soungs from an AES encrypted ext3 fs.
– Samba, ntpd, sshd and the usual system daemons running on the NSLU. No other servers though.
– Soundbridge M1001 via LAN connected
– Soundbridge HomeMusic via WLAN/WPA connected
What works:
1. Both Soundbridges acessing an mp3 on the firefly server plus copying a file from/to the NSLU via samba or scp. No rebuffering.
2. One Soundbridge accessing an .ogg which is transcoded to wav and streamed. The other soundbridge accessing a .mp3. No rebufferings, works nicely. Accessing the harddisk on the NSLU via samba or scp in addition does lead to sporadic rebufferings via LAN. Heavy rebuffering when done via WLAN, which is more a WLAN capacity issue then.
3. Both soundbridges accessing an .ogg, so double transcoding required! Works with sporadic rebufferings, mostly going ok. This load is apparently at the edge what the CPU can do. Please note that the NSLU also has to decrypt the AES ext3 fs, so without the AES this would likely work without rebuffering, if only one of the streams goes via WLAN.
4. Accessing the same file on the NSLU at the same time is no problem. Playback just isnt synchronous then.
5. One Soundbridge playing from firefly and one an internet stream works also obviously.
6. I could not notice much difference when a background filescan was triggered via the webinterface. Except for 3. which rebuffers more then.
What should likely work:
1. Accessing the NSLU with up to 4 Soundbridges without transcoding involved. If you do away with the AES and strip down to minimum amount of processes running then I could imagine more are possible as well.
2. Three Soundbridges accessing mp3’s plus some file copies via samba should likely also work.
===========================
Quite impressive what is possible thanks to the lean design of the firefly server.