advertisement


MDAC first listen thread

Status
Not open for further replies.
Its no Crown* If things don't fit, move on, you don't accrue loyalty points - not in this game. I don't see the point in wishful thinking just for the sake of investment.
Cut your losses ASAP, IMO. Or buy for less than you can sell them for and make a profit ;).

* Notice the capital 'C' :)

Anyway.....My amp and speakers are here to stay.
 
Any SPDIF receiver must, in the long term, lock to the incoming clock rate if it's to avoid the need, sooner or later, to roll over. Bear in mind that the long term clock accuracy of some domestic kit is generally not fantastic. A buffer can help you avoid short term issues but if the clock isn't spot on, the tub will eventually overflow or run dry.

I'm a bit surprised that you're suggesting that this effect is audible. In the 70's I had a digital watch which was accurate to less than a second a month. In fact it kept time remarkably well, and seldom lost more than a few seconds a year. Given that it is now 2011, and chips are cheap as... chips, how is it that the ones used in DACs are so much worse than my 1970's budget didge? If they're equivalent to my didge, then they must be differing by what, 1/10th of a second a day? My DACMagic buffer takes about a second to fill, so presumably it could play for a solid ten days before clock discrepancy over S/PDIF would cause a one second glitch. I think I could tolerate a one second glitch every ten days of continuous play. Where am I going wrong?
 
It could be that Pulse Audio is the culprit, I am pretty sure it defaults to 44100 unless you explicitly set it to something else.

Yes, pulse audio is indeed the culprit. I can set it to 44.1 or 96KHz but not pass through which is a bit odd. I will post a question on Ubuntu forums for a way round this. It will be flak I will get on there not FLAC, for suggesting that 128K MP3 is somehow not quite adequate but here goes...
 
Ooops. Linux user here. In XBMC Linux, just set the 'custom output device' to plughw:1,0 , that'll get you going.

If pulseaudio is installed, XBMC _will_ try to resample by default so using the plughw handle to go directly to the hardware works best for bit perfectness.

Works a peach, including the HID controls via the remote.

Russel,

Not sure if you noticed this posting from dtd, but seems related to your Linux issue, but what do I know as i'm still on XP...
 
Russel,

Not sure if you noticed this posting from dtd, but seems related to your Linux issu, but what do I know as i'm still on XP...

It's very related. I had the exact same issue till I did the above. In any app, just set plughw:1,0 as the output device and hey presto.
 
good explanation....i still feel that jitter is not the holy grail of good digital as i have heard some nasty sounding digital gear with ultra low jitter so it can't be the only unique selling point even if people would want it to be.....
Nobody's said it's THE holy grail.

But it's a very significant part of the difference between extremely good and less good
 
Russel,

Not sure if you noticed this posting from dtd, but seems related to your Linux issu, but what do I know as i'm still on XP...

Yes, thats the Alsa audio config whilst mine is currently using pulseaudio which it looks like it does not support passthrough. I might try and deinstall pulse and go to Alsa, which is supposed to have been surpassed by pulseaudio, such is progress!
 
Yes, thats the Alsa audio config whilst mine is currently using pulseaudio which it looks like it does not support passthrough. I might try and deinstall pulse and go to Alsa, which is supposed to have been surpassed by pulseaudio, such is progress!

You wont need to uninstall pulseaudio should you just point directly to the handle mentioned above.
 
Where am I going wrong?
In that I never have said this is audible - in truth, I do not know!

But it is important in the context of a DAC that needs to provide continuous service, for whatever reason. The bigger the buffer you operate, the greater the latency. I suspect 'excessive' (whatever that means) latency is considered unacceptable for some reason. Any deeper reasons than this will have to come from your local friendly DAC designer!

In the domestic environment, a DAC has to be designed to track all kinds of poor quality incoming clocks, and lock quickly. A clock expert once told me that if domestic users were willing to tolerate a 1 minute lock up period before a DAC declared itself 'locked and ready', jitter would simply not be an issue!
 
FYI for linux users : MPD (Music Playback Daemon) set to plughw:1,0 - both bit perfect test passed, but took a few attempts.
 
Status
Not open for further replies.


advertisement


Back
Top