PDA

View Full Version : Streaming vs direct file access



audio1
2010-07-18, 08:34
Hello. A technical question, please: can someone comment on the technical/practical differences between the "streaming" network audio model, as used by Squeezebox and many other commercial devices, compared to a conventional music playback application (such as XMMS/Rhythmbox/Amarok/Aqualung) which accesses music files over a network via NFS or SMB protocol?
The latter seems more technically straightforward to me.
Is the prevalence and popularity of streaming only because of the ability to have multiple clients, and multiple outputs?

snarlydwarf
2010-07-18, 18:55
Hello. A technical question, please: can someone comment on the technical/practical differences between the "streaming" network audio model, as used by Squeezebox and many other commercial devices, compared to a conventional music playback application (such as XMMS/Rhythmbox/Amarok/Aqualung) which accesses music files over a network via NFS or SMB protocol?
The latter seems more technically straightforward to me.
Is the prevalence and popularity of streaming only because of the ability to have multiple clients, and multiple outputs?

Reading files via NFS/SMB and even UPNP type protocols does not give you the indexing that a proper server would. Ie, there is no NFS or SMB API for "please show me all the tracks with genre 'Foo'". Likewise there is no API for tracking playcounts, ratings, etc.

If you use simply one player, then I guess that doesn't matter: if the player is sufficiently fat, it could make its own index by scanning files. but if you have more than one player, why have more than one index? How would you synchronize ratings etc.

heck, if you only have one client, why even bother with NFS: just attach the hard drive directly to the "player". Adding NFS or SMB seems to just complicate things more with a single player.

funkstar
2010-07-19, 03:49
Reading files via NFS/SMB and even UPNP type protocols does not give you the indexing that a proper server would. Ie, there is no NFS or SMB API for "please show me all the tracks with genre 'Foo'". Likewise there is no API for tracking playcounts, ratings, etc.
Add to this, sync wouldn't be possible.


audio1, the latter definitely is more straight forward and a lot easier to impliment, but it is very basic and not very flexible.

audio1
2010-07-19, 20:32
Thanks for your comments snarlydwarf and funkstar,
As I look towards updating my music playback system in the near future, I want to thoroughly understand the fundamental configuration options.
It appears to me that central to the choice of hardware/software/configuration is whether you want a single player or multiple players.


if the player is sufficiently fat, it could make its own index by scanning files.
Yes, the major Linux audio player applications do create their own databases. Amarok2 uses MySQL for example, while Banshee uses SQLite, and Exaile uses a unique database format. A shortcoming of this is that the databases are not dynamic; they must be refreshed manually.
I'm not interested in multiple players, but if I was, it's possible to configure multiple players (assuming they're all the same type) to share a common database/configuration directory on the network, making the database common to all players.


there is no NFS or SMB API for "please show me all the tracks with genre 'Foo'".
Likewise, there is no streaming API for "please show me all the tracks with genre 'Foo'".
But this is slightly off-topic to my original question, which related to the delivery mechanism of the media file to playback device.


if you only have one client, why even bother with NFS: just attach the hard drive directly to the "player".
Yes, I take your point that it's somewhat overcomplicated to have a single player access its music store over a network.
The reason I mention network connectivity within a single-player environment is that I envisage using a "lightweight" computer for playback duty in the lounge room - maybe a small Atom machine, or ARM embedded device, or even Android tablet,
but I envisage using a conventional personal computer in the study or bedroom as the ripping/acquisition machine. Obviously one of these devices would have the music storage drive connected locally, and the other would access this drive over the network.
Wait ... there's a third scenario - a separate NAS which is accessed by both the ripping computer and playback computer.

In the 2 scenarios where my (single) playback computer is NOT connected directly to the music storage drive, I continue to wonder about the technical merit of generating an audio stream.

snarlydwarf
2010-07-19, 20:51
Thanks for your comments snarlydwarf and funkstar,
As I look towards updating my music playback system in the near future, I want to thoroughly understand the fundamental configuration options.
It appears to me that central to the choice of hardware/software/configuration is whether you want a single player or multiple players.

Yes, a multiple player setup, by nature, requires some sort of 'client/server' protocol. NFS and SMB are going to require a lot more work on the client side: neither addresses the database itself. I see no benefit to such a process other than moving some work from userspace to kernel space.. but the code to serve files is actually HTTP: which is well understood and easy to implement... so whether a file is moved via nfsd or an http socket really makes no difference.

And, again, using just NFS/SMB, you have no shared database.



Yes, the major Linux audio player applications do create their own databases. Amarok2 uses MySQL for example, while Banshee uses SQLite, and Exaile uses a unique database format. A shortcoming of this is that the databases are not dynamic; they must be refreshed manually.

SBS 7.6 (the current dev snapshot) uses inotify on Linux.. no need to rescan to find things. The kernel sends it an inotify event and SBS knows where to look for the additions/changes.



I'm not interested in multiple players, but if I was, it's possible to configure multiple players (assuming they're all the same type) to share a common database/configuration directory on the network, making the database common to all players.


Which is what SBS does (and more, but more on that later).

As for not being interested in multiple players: I am sure most people in this forunm said that at one time, and now have several squeezeboxes. I lasted a couple months before I had to get another.



But this is slightly off-topic to my original question, which related to the delivery mechanism of the media file to playback device.


No, it's not. there is more to things than delivery mechanism. If that is truly all you care about: the Squeezeboxes make HTTP requests for files that are sent via HTTP.

HTTP is a better protocol for "can I have this file?" than either SMB or NFS which are MUCH more complicated and contain code that is entirely irrelevant to simply sending a file.



Yes, I take your point that it's somewhat overcomplicated to have a single player access its music store over a network.
The reason I mention network connectivity within a single-player environment is that I envisage using a "lightweight" computer for playback duty in the lounge room - maybe a small Atom machine, or ARM embedded device, or even Android tablet,
but I envisage using a conventional personal computer in the study or bedroom as the ripping/acquisition machine. Obviously one of these devices would have the music storage drive connected locally, and the other would access this drive over the network.
Wait ... there's a third scenario - a separate NAS which is accessed by both the ripping computer and playback computer.

In the 2 scenarios where my (single) playback computer is NOT connected directly to the music storage drive, I continue to wonder about the technical merit of generating an audio stream.

If you have s single player and think you can find an off the shelf ARM embedded machine with decent sound output, then go for it.

If, however, you ever add a second player.. your method would not scale, It would not allow syncronizing the players, you would have to hobble together your own UI (or have to use a netbook as a remote...)

Squeezeboxes don't have that scaling problem. They scale very well, they can be synchronized or not.

erland
2010-07-19, 21:34
Yes, I take your point that it's somewhat overcomplicated to have a single player access its music store over a network.
The reason I mention network connectivity within a single-player environment is that I envisage using a "lightweight" computer for playback duty in the lounge room - maybe a small Atom machine, or ARM embedded device, or even Android tablet,

Are you looking for really great sound quality ?
Is the price of this lightweight computer important ?
Do you won't be able to see what's playing when you are in the lounge ?
Do you want to be able to change what's playing when you are in the lounge without the need for a separate keyboard in the lounge ?

If the answer is yes on all these questions, I think you can forget the idea of an embedded Atom or ARM machine. What you need is either is one of three options:

Option 1:
Get a commercial network music player such as a Sonos solution or a Squeezebox. Sonos might cause you less setup/maintenance trouble while a Squeezebox will have the advantage when looking at price, features and sound quality.

Option 2:
Get an iPod, iPad or some other portable device with music locally stored on the device and a docking station connected to the amplifier/speakers where you put it when you like to listen to music. You would probably have to sync it with the bedroom computer when you want to add new music, at least in the case where you select and Apple product. The advantage with this solution is that you will also get a portable player that can be used when you leave your home.

Option 3:
Get a simple UPnP based network music players, they are usually cheaper than Squeezebox, Sonos and similar more advanced solutions and they usually doesn't produce the same sound quality and library browsing features. Still, it might be an option if the price is more important than everything else.

Sure, you can build your own Atom or ARM based device if you think that's fun but I bet it's going to be more expensive and won't produce as good sound quality as the above options. However, if you answered No on one of the questions above, an Atom/ARM solution might be worth considering.

As mentioned earlier in the thread, the main advantage of streaming compared to NFS and similar protocols is if you like to synchronize audio on multiple players.

audio1
2010-07-20, 05:57
HTTP is a better protocol for "can I have this file?" than either SMB or NFS which are MUCH more complicated and contain code that is entirely irrelevant to simply sending a file.
OK, that's the kind of information I want to know about. Can you elaborate, please? I'm happy to learn.

erland, thanks for your hardware suggestions. I take it all on board, but to clarify my aim; I consciously want to build and configure my own system, and I'm under no illusion this will save me time or money. It's a matter of satisfaction. I have already partially built up my own hifi system, and I'm fortunate to have the assistance of some technicians who are more clever than I.



Are you looking for really great sound quality ?
Yes, the very best audiophile output.



If you have a single player and think you can find an off the shelf ARM embedded machine with decent sound output, then go for it.
Off the shelf, no. Modified/hacked off the shelf product, yes. Initially I will configure the device for USB audio output to a high end USB DAC, with asynchronous clock and good power supplies.

snarlydwarf
2010-07-20, 10:51
OK, that's the kind of information I want to know about. Can you elaborate, please? I'm happy to learn.

Pushing 'next' on my radio generates the following:

POST /cometd HTTP/1.1..User-Agent: SqueezePlay-baby/7.6.0-r8934 (armv5tejl)..Content-Length: 142..Host: <ip>:9000..Content-Type: text/json..Accept-Language: en....[{"id":383,"data":{"request":["00:04:20:xx:
xx:xx",["button","jump_fwd"]],"response":"\/fdbe4a6b\/slim\/request"},"channel":"\/slim\/request"}].}

ie, "user pressed 'jump_fwd' button"

Server responds two ways:
Direct response to the POST:
HTTP/1.1 200 OK..Server: Squeezebox Server (7.6.0 - 30967)..Cache-Control: no-cache..Pragma: no-cache..Content-Length: 72..Content-Type: application/json..Expires: -1..X-Time-To-Serve: 0.0647580623626709....[{"clientId":null,"id":387,"channel":"/slim/request","successful":true}]

And SlimProto:
.Qstrms1m????...0.......#(....GET /stream.mp3?player=00:04:20:xx:xx:xx HTTP/1.0....

Which is basically "Please dump the existing buffered stream, and go get this stream"

Player responds by executing the GET the server told it to do:
GET /stream.mp3?player=00:04:20:xx:xx:xx HTTP/1.0....

Not very complicated. I am probably missing some stuff, I am at work, and it is spammy
to sniff my home network from here. (And, yes, my radio is next to me at work, but on a different
network where bandwidth is cheaper and since that is on a cable modem, as is my home system,
the latency is virtually nothing.)

If I was syncing, there would be more complexity keeping track of where multiple
players were in the output stream, but I'm not at the moment.

The newer players 'mostly' use HTTP with some low level stuff passed back as slimproto,
(which is documented in the server docs). The stream, however, was your question, and that is
just HTTP.

erland
2010-07-20, 11:15
erland, thanks for your hardware suggestions. I take it all on board, but to clarify my aim; I consciously want to build and configure my own system, and I'm under no illusion this will save me time or money. It's a matter of satisfaction. I have already partially built up my own hifi system, and I'm fortunate to have the assistance of some technicians who are more clever than I.

Ok, the big problem with a computer and high quality audio as I've understood is that there are too much electronics in a computer which results in various kind of interference. Less electronics results in less risk of interferences between the circuits. I'm no expert at this so I really don't know what causes the interference but I suspect things like the power supply unit and any fans or hard drives are good candidates. I'm guessing it might also be possible to somehow shield the audio circuits to minimize the risk and high quality audio circuits are probably better than low quality. I'm sure you are already aware of most of this and you are probably also aware of that it's not that easy to design a computer with high quality audio output. Just getting a high quality sound card is usually not enough.

audio1
2010-07-21, 08:24
snarlydwarf, thanks for the HTTP stuff. I'm showing it to some other people who can hopefully expand on it and help me understand further.
I'm becoming comfortable with the SB configuration model, and I'm now contemplating running SB Server in conjunction with SqueezeSlave.
In a single player setup, I still prefer the straightforward model employed by Music Player Daemon, but after your comments about scalability, I must say that MPD gets messy if you want to run different outputs to multiple players.
As you say, SB scales well.

erland,
Audiophile computer playback is discussed extensively on diyaudio.com and computeraudiophile.com. There's little point repeating the discussions here.
Yes, computer electronic noise is a problem, but this is less so when the computer is small/low power, and has no hard drive. The SB Touch is, of course, a device which fits this description, and John Swenson's efforts to tweak the Touch are convergent, in my opinion, with audio development efforts with general purpose computers.