MDAC First Listen (Part 00101010)
- Thread starter jirij
- Start date
- Status
The difficulties are in the "low latency" part.
I don't know what slimdevices did 10 years ago, but it was probably either RTSP based or plainly HTTP based - similar to "file download". This is perfectly possible and if HTTP is used (RTSP itself being HTTP-esque), congestion control is done by TCP and the transfer rate adjusts to the playback rate. The problem is that this really works only for static files and things like the URL need to be entered via some interface on the receiver.
Maybe - DLNA defines the controlling protocol as HTTP, but as RTSP is very similar to HTTP in terms of headers, request/reply and error codes, etc., it might be just misunderstanding on the DLNA site. If it is indeed renderer-controlled, it will likely use the same TCP congestion control mechanism as simple HTTP file download. However you can't just apply a high level concept (renderer pulling data) to a lower level protocol simply because "it makes sense".
How would that work? Why should Squeezebox be different from any other RTSP/RTP setup?
Right, but both are referred to by people as "network playback" (or similar).
"Streamer" is just a generic computer running specialized software doing a specific job that would be too mentally complex for the person. The same job can be done by a dedicated microcontroller (like the one JohnW is going to use for wifi/bluetooth), so implementing one into FDAC (or rather some future DAC given current timescales) could be as simple as "just" adding a SoC solution and slapping on an ethernet port.
I'm excited about AVB because it's finally somewhat complete solution for audio networking in the real sense (2nd scenario) - very low latencies (dedicated 802.1Qav ASICs), bandwidth guarantees, distributed clock, etc. -- basically the stuff really relevant to a DAC. Imagine the possibilities for something like FDAC master/slave setup - you could have slaves around the house with one master providing the clock, to which your computer is locked (and is streaming the music) with you being able to control the volume and connect/disconnect slaves from your phone, lock them onto a different clock and a different computer, etc.
All this not just limited to some music playing app, but to everything - movie sounds, you jamming the guitar, everything properly low latency & real time.
Slapping a mini computer inside the DAC (for DLNA/RTSP/HTTP/whatever streaming) is just boring and doesn't make much sense to me besides the whole "one box rules them all" idea.
(But I can indeed see some convenience benefits.)
Beware! Before you realize it, it's going to have a DVI port, a web browser - just in case you want to check the forum without powering your "real" computer!
Indeed, but not just because I say so.
Reread Rune's post that I quoted. The particular conversation that has been going on is about the DAC network equivalent of USB. No streamer.
Indeed the systems/protocols being discussed such as avb allow the use of multiple network connected synchronised DACs. For example, each speaker containing its own active system and connected via the LAN - the equivalent of, say, a USB connection to each speaker.
An equivalent system based around current streamer implementations would have the DACs all connected to the inside of the streamer, not all the DACs connected to the LAN
iansr
pfm Member
At one point I suggested that John and Dominik should develop a renderer (in due course!) but then the scales fell from my eyes and I saw that if the Detox is largely successful then, as I subsequently posted, it will level the playing field for renderers and a cheap SBC based one ought to perform as well as an expensive "high end" one. In other words, I agree with you Rune.
Paul R
pfm Member
Server asks Squeezebox 'how much room do you have in your buffer?' Squeezebox replies '345434 bytes', Server says 'Here's 262144 bytes to add'.
Perhaps you're over-thinking this. The basic argument is if you're putting a processor inside a DAC, such as to manage USB, perhaps it makes more sense to use that processor to put the DAC on the network. It can then be addressed in a more general way than as a tethered peripheral of a particular PC. If you use standard protocols then the DAC is turned into a streamer, but from the user's pov it results in the same thing.
Paul
ti33er
pfm Member
The OPPO is a very nice Streamer and does just about everything in addition ...they even have Tidal (lossless) streaming ability now
Hoping John or MiniDSP will have some HDMI jitter reduction circuit like AUDIOLAB did on the 8200AP or like ANTHEM with their HDMI solution (assuming the FDAC HDMI port will feign a small Video signal to receive Audio - although Oppo has a Music only mode that shuts down the video circuitry, if that works out alternatively)!
The chances of me using USB are slim, being honest as I'm no Computerphile when it comes to AV
Hoping John or MiniDSP will have some HDMI jitter reduction circuit like AUDIOLAB did on the 8200AP or like ANTHEM with their HDMI solution (assuming the FDAC HDMI port will feign a small Video signal to receive Audio - although Oppo has a Music only mode that shuts down the video circuitry, if that works out alternatively)!
The chances of me using USB are slim, being honest as I'm no Computerphile when it comes to AV
If you don't want to fiddle with computers you could also consider the Auralic Aries mini which should be available in October at around £350 and use the Detox with that.The OPPO is a very nice Streamer and does just about everything in addition ...they even have Tidal (lossless) streaming ability now
Hoping John or MiniDSP will have some HDMI jitter reduction circuit like AUDIOLAB did on the 8200AP or like ANTHEM with their HDMI solution (assuming the FDAC HDMI port will feign a small Video signal to receive Audio - although Oppo has a Music only mode that shuts down the video circuitry, if that works out alternatively)!
The chances of me using USB are slim, being honest as I'm no Computerphile when it comes to AV
uwe061
pfm Member
Being a DAC designer provides you with knowledge that the majority of us, like myself, do not possess...so yes, many times there IS a "lack of understanding of the underlying issues". But isn't that why most if not all of us subscribe to forums like this? That being said, I will admit that I do not understand the highly technical content of a signficant number of posts here. In those cases, I try to get the gist and not obsess over the details.
I personally have NOT read JohnW's reports but would like to. Can you provide links?
Thanks.
timola
pfm Member
+1....I did read JohnW's post...but have little to no understanding of underlying technicalities...and like you try and get the gist of things...and sometimes jump to the wrong conclusions.
Richard Kimber
pfm Member
I'm not quite sure what kind of context you are thinking about. Don't we normally have static files? The 'URL' for the file is in effect entered automatically by the dlna control app when you select your piece of music with a click. So I don't see why there's a problem. In what context does the "low latency" part become an issue?
- Richard.
iansr
pfm Member
Have you seen any reviews of it yet ? ( for what they are worth . . . )
Being touted as the new SB Touch. Shame they don't sell a cheaper version sans DAC.
Have not seen any reviews. Don't think they will release a cheaper version sans DAC because that would undermine the sales of the Aries or Aries LE.
It becomes an issue in virtually any other use case. As mentioned, synchronization with video, using multiple DACs / speakers on multiple places, when interacting with the music (ie. editing in a DAW), when recording from multiple ADCs (where you need phase coherency) or needing fast feedback (ie. playback of samples for a MIDI keyboard under ~10ms).
I imagine other people would come up with more use cases. Like a DJ, who needs to synchronize ("mix") tracks on-the-fly perfectly.
It may have come across badly, but I really don't have a problem with file based playback or "DACs" being DLNA renderers (although it's a weird fetish
), I see the use case for the majority of hifi audience, my complaints were directed at it being thought of as "better than USB" or "why don't DACs do DLNA instead of USB" and while the definition of "better" is very relative, losing the real-time aspect of standalone DACs would push them more into the niche territory of a stereotypical creepy old man, which is not something I'd like to see.(PS: USB isn't really that great in terms of low latency, but it's still below the human noticeability line.)
clivem2
pfm Member
John, have you seen this new device from iFi?
http://ifi-audio.com/portfolio-view/micro-iusb3-0/
http://ifi-audio.com/portfolio-view/micro-iusb3-0/
Sounds interesting, although there may be a big gap between the marketing materials and the implementation of the technology.
And the price is £325
JohnW
pfm member
Hi Clive,
I know of the device via the internet only, but not seen or measured one.
The Detox basically does much the same but with the added features of a MDAC / FDAC clocklock interface (very important), Spread spectrum clock mode (I think this will be rather cool and generate much debate) and I suspect greater jitter / RF attenuation by the use of x3 cascaded hubs (But note I've not measured the iFI unit).
The iFI micro does support USB 3.0 - but we are not in ANYWAY limited by USB2.0 data rate for multichannel HiRes audio applications - the iFI also supports 2.5A total USB power, but USB2.0 is limited to 1A with later revision to support Fast Charge - but again this does not impact the use with DAC's / MDAC / FDAC.
I'm constantly receiving Emails about problems using the MDAC with USB 3.0 ports so I would only recommend using "true" USB1.1 / USB2.0 ports.
It be good to see some measurements and more details - the website is rather full of marketing BS then "real" information. Its possible all the technical details have been filtered by the marketing Dept. I've seen what happen at Audiolab...
May the best man win
- Status