seanadams;216027 Wrote: > Not at all. You still have to _get_ all that data to the player. And you > still have to be able to generate some audible rendition of it as you > scan through the compressed stream. And you still have several of the > other issues I originally mentioned, such as supporting the myriad of > formats. So only if you had unlimited RAM, CPU, and bandwidth, and only > one format to support would it be "trivial". And as long as you're > having all that, why not a pony too? :)
Sure, as long as someone else pays for feeding and housing the thing... :P How I would solve it given infinite memory: decode the whole track and then the position of the sound at X seconds is derivable via multiplication. A faster CPU would help, too, so that more of the track could be decoded in background to anticipate forward movemeent. That would keep ff/rew in the client. I am not sure if bandwidth would help that much in cases of short ff's and wouldnt help at all in rewinds. But then were specing a reeasonably hefty CPU and memory... RAM is certainly cheap, but CPUs can be spendy, and the market for a $1000 device is a lot smaller (and of course faster CPUs almost always mean more heat...) That is most likely how MCE does it, with a sliding window instead of the whole file to save RAM, but still there is a lot more RAM. > > Anyway if you could only change one of those things, I'd say the best > one would be the bandwidth. If you're guaranteed the throughput, low > latency, and zero packet loss of 100Mbps ethernet (as in the DVR > example) then the problem becomes a LOT more manageable. More RAM is > nice but certainly wouldn't solve the problem per se. Well the DVR example also allows for a lot more intelligence in the client, and this is not even universal on Windows apps. (For some reason WMP will play AVI's stored on an SMB-mount, but Winaamp rarely works... some need in Winamp to seek or something is not implemented the same for SMB as it is in local access) Given infinite resources, the problem is easy, but then so are most problems. (It would be possible to design a chess-playing computer much like the always-winning checkers machine announced this week... assuming infinite CPU power to process the entire tree of potential moves and infinite memory store the results... the 50-move rule ensures that there is an end to any game. A decisiion tree could never be more than 30*50 nodes deep.) But, yes, given the real world constraints throwing 1G of memory and a 1Ghz CPU and 100W of heat into a music player to solve this is silly. In the real world, it is a hard problem. -- snarlydwarf ------------------------------------------------------------------------ snarlydwarf's Profile: http://forums.slimdevices.com/member.php?userid=1179 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
