(spinning a new thread from http://forums.slimdevices.com/showpost.php?p=211286&postcount=45)
amey01;211286 Wrote: > Before we start adding even more features to the Squeezebox, let's just > get what we've got working - and working properly. > > FF and REWIND that works as well (not better - just "as well") as a > circa 1982 CD player would be a start! This is about the same as complaining that you can't "scratch" on a CD player the same way you could on last century's phonograph... except that in this case it is a bit less obvious why you can't. It's clear from the tone of your comment that you don't care why, you just want it to work. That's fine, you can stop reading here, but in case anyone else wants to know, I will explain. Before getting into the specifics of why this doesn't work on Squeezebox, it's helpful to understand some details of how FF/RW scanning works on a CD player, since that is the behavior we want to emulate. CDs and LPs have a few things in common, and for the purpose of understanding how FF/RW work, the LP is a helpful conceptual model. The data on a CD is laid out similarly, in a spiral, which for normal playback is read continuously from start to finish. There is no compression and essentially no structure to the data - it's just a series of [bits which represent] amplitudes. So much like an LP, you can move the "pickup" radially across the disc and instantly continue playing at any new point. And this is really all a CD player is doing when you scan. It plays at normal speed for a fraction of a second, and then the pickup skips a few rings, and it continues playing again at a new point for a fraction of a second, and so on until the ff/rw button is released. The rotation speed of the disc does not change, and neither does the playback rate or the data rate. The head just skips along. So there is really nothing to it; the capability is "free". It's also helpful to contrast this to a tape deck, where although you can scan by simply moving the tape faster, it can't be done without sounding like chipmunks because the transport can't alternate quickly between skipping ahead and playing at 1x. So what's different about Squeezebox that makes this hard? It's not so much the "Slim" architecture. In fact, being "Slim" would work significantly in our favor if one were to try and implement this (not that I think that's a good idea, more on that later). Really the challenges are just inherent in network streaming: 1) The data is typically compressed. That means you can't just pick up at any point in the stream and instantly start playing. You have to get to the next "frame". Every format has different size frames, and many can even be variable in size. For some formats it is not possible to know how far to look ahead in order to advance by some amount of time. You either have to guesstimate and then resync, or you have to process every frame in between. You may even have to scan through a significant amount of data before you can resynchronize and continue decoding. So the problem is that in order implement ff/rw the way a CD player does, you have to break the stream up into short "blurps" and due to the way the data is organized this can be practically impossible without decoding the entire stream. Even if you had instant random access, scanning ahead is complex. 2) You don't have instant random access. This is because data comes over the network in small chunks at nondeterministic intervals, and there is an appreciable delay between requesting a particular piece of data and receiving it. In order to quickly move to a different point in the stream, you would need to implement a very sophisticated buffering scheme, which would probably have to be different for scanning forwards vs backwards. In the case of scanning forward, you might take advantage of the fact that there is already some data buffered for the purpose of normal playback, and so you could scan through that first before needing more data from the server. For scanning backward, you might try to save some amount of data that had already been played, but this would obviously compromise the amount of memory that is otherwise available for nomal buffering. 3) It's not possible for us to decode at more than 1x. This means that any scanning algorithm would have to be very smart and deal with the compressed data intelligently to figure out which blurps to decode. Since every format is different, this means a different algorithm for every one. 4) Bandwidth is limited. We can't just instantly double (or more) our demand on the network and expect data to flow normally. Especially if we require rapid bursty transfers as opposed to a continuous flow of data. So that means that we can't have the client scanning through the compressed data stream. It has to be done on the server, and then a "chopped up" stream sent to the player. 5) Transcoded formats are a special case. Currently our transcoding capability does not support seeking of any kind within a track, let alone the rapid scanning capability that might be required. To make transcoded formats seekable would require not only special algorithms to be added to every decoder, but also a new architecture whereby the server could communicate these seek commands to the decoder. 6) code complexity. This is the real #1 reason why this _should not_ be done. Scanning would not be impossible to implement. An extremely dedicated programmer could probably get it working reasonably well, at least for a few of the audio formats we support, in a few months. But to do so would require adding all kinds of complexity and special cases to dozens of different parts of the system - I mean everything from the most mundane like the time elapsed display, to perhaps the most intricate bits of the audio codecs. So the obvious questions of a) can it be done b)how long would it take, c) is there something better this developer could be working on, are not even the deal breakers. What is a deal breaker is that even if one were to implement it, you'd be left with a massively more fragile and difficult to maintain code base. So it's ironic that it is usually the same people who complain about slimserver's stability that also scream for some marginal feature to be added. Featuritis and stability and simply incompatible goals, and to make the assertion that ff/rw is an essential or trivial feature that must be implemented, while at the same time calling for software that just works, is not really constructive. Most of us have little or no need for scanning, and just because a CD player does it does not automatically mean it is a good idea to make Squeezebox do it. -- seanadams ------------------------------------------------------------------------ seanadams's Profile: http://forums.slimdevices.com/member.php?userid=3 View this thread: http://forums.slimdevices.com/showthread.php?t=36446 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
