Back to this subject. As Søren earlier replied this is indeed just another compression algorithm. However, it can be decoded by hardware as well. For example Tidal now offers MQA-files for streaming. In the application settings you can also choose hardware decoding for the stream and I believe that there are a few compatible DACs already around. MQA decoding compability would be an interesting feature in DAM as well if it is possible to implement by a firmware update.
Could someone explain to me why it would matter?
You pick a data source, play it using your preferred player, send it to the dac and so on. Everything should be bit perfect or something is wrong. Decoding the stream in the dam would only put higher stress on the dac and the player of choice will have a much more powerful CPU regardless. Since the dam is asynchronous everything is reclocked locally irrespective of source.
Maybe there could be an upside in data transfer protocols but that would only matter if your source is unable to produce a signal that the dam can lock on to properly? The dam isn't intended as a standalone streaming client, it's a dac? Maybe I'm missing something obvious?
Until there is native support of a network connection, hardware decoding seems moot?
You pick a data source, play it using your preferred player, send it to the dac and so on. Everything should be bit perfect or something is wrong. Decoding the stream in the dam would only put higher stress on the dac and the player of choice will have a much more powerful CPU regardless. Since the dam is asynchronous everything is reclocked locally irrespective of source.
Maybe there could be an upside in data transfer protocols but that would only matter if your source is unable to produce a signal that the dam can lock on to properly? The dam isn't intended as a standalone streaming client, it's a dac? Maybe I'm missing something obvious?
Until there is native support of a network connection, hardware decoding seems moot?
The OS is Archphile. Player software is goold old Music Player Daemon (MPD). Though I'm not using the latest version of MPD (I'm on 0.19.14). Haven't had time to try a newer version yet.
I actually have an Odroid C2, though I haven't even turned it on yet. The problem (for me) with Odroid C2 is that I'm using Normunds's input board, which allows for convenient mating of the Soekris boards to the RPi; this board is incompatible with the C2 because the C2 has a different pinout for the I2s lines. (I've been thinking about trying to design a similar board for the DAM1121 (OEM module) that would work with either the C2 or RPi, but that requires time I don't have at the moment.)
I could hack up some temporary wiring to give the C2 a try in this role. But another problem is this weird sync loss issue is non-deterministic so far; it comes and goes at random. If I could consistently reproduce it, then it'd be worthwhile to swap in the C2.
Also, while I know the RPi shares a bus between Ethernet and USB, in this application I'm not using the USB at all, so the Ethernet should be effectively on its own bus. Also, this is 44/16 FLAC over a 1gbps connection, that's a pretty light load, even for a junky shared bus. I would think if the Ethernet were the issue, the sync loss would occur at different points in the song. That this occurs (so far) exclusively at the start of a track I think is a clue.
Today Lampizator published on his facebook that "all dac models were tested on MQA.."
Lampizator Atlantic is based on Soekris 1021
Soekris is able to play MQA. Isn't it?
An externally hosted image should be here but it was not working when we last tested it.
Lampizator Atlantic is based on Soekris 1021
Soekris is able to play MQA. Isn't it?
MQA is just another lossy compression codec with content management, with the constant increase in bandwidth avaliable it will be obsolete in a couple of years and forgotten again....
I see absolute no reason to put it in hardware, especially not when there is royalty payments and copy protection involved....
I see absolute no reason to put it in hardware, especially not when there is royalty payments and copy protection involved....
Thank Søren for pointing out your view on this and I understand your reluctance due to the high effort that it would require and kind of a rip off royalties for the technology.
Those who are criticizing, I recommend reading the following article though. Some technical points about MQA being also a process that corrects part of the A/D and D/A conversion errors when the recording and playback equipment is known. I know that part of this might be just marketing nonsense, but even if half is true, then I believe it could open up new possibilities comparing to normal 16bit/41 kHz lossless stream.
http://www.digitalaudioreview.net/2016/06/an-inconvenient-truth-mqa-sounds-better/
Those who are criticizing, I recommend reading the following article though. Some technical points about MQA being also a process that corrects part of the A/D and D/A conversion errors when the recording and playback equipment is known. I know that part of this might be just marketing nonsense, but even if half is true, then I believe it could open up new possibilities comparing to normal 16bit/41 kHz lossless stream.
http://www.digitalaudioreview.net/2016/06/an-inconvenient-truth-mqa-sounds-better/
Last edited:
And here is a counter-offer: is-mqa-doa
https://benchmarkmedia.com/blogs/application_notes/163302855-is-mqa-doa
This is a more scientific oriented article NB.
//
https://benchmarkmedia.com/blogs/application_notes/163302855-is-mqa-doa
This is a more scientific oriented article NB.
//
Last edited:
ummm...
That is a regurgitation of MQA's marketing speak and not a critical analysis. MQA compression algorithm adds considerable alias artifacts to the decoded file. See the independent spectral analysis at computer audiophile.com:
http://www.computeraudiophile.com/f8-general-forum/mqa-spectrum-plots-31199/
MQA is a dangerous thing... It may result in less real hi res audio being released in favor of MQA (faux hi res). The marketing of MQA and the term "master quality authenticated" is really disturbing as well, as these files bear no resemblance to the master. Real hi res files, like Reference Recordings HRx discs are actually direct copies of the master, MQA is a lossy compression format.
That is a regurgitation of MQA's marketing speak and not a critical analysis. MQA compression algorithm adds considerable alias artifacts to the decoded file. See the independent spectral analysis at computer audiophile.com:
http://www.computeraudiophile.com/f8-general-forum/mqa-spectrum-plots-31199/
MQA is a dangerous thing... It may result in less real hi res audio being released in favor of MQA (faux hi res). The marketing of MQA and the term "master quality authenticated" is really disturbing as well, as these files bear no resemblance to the master. Real hi res files, like Reference Recordings HRx discs are actually direct copies of the master, MQA is a lossy compression format.
Last edited:
Transistor Hfe is not critical, but please note that the vref buffers in rev3 or newer is better than that old mod....
Hi All!
I'm just about to start with my third Soekris DAM 1021 (rev.3)-build up. I used to power the board with an ultra solid linear regulated (LM 1084 ADJ) PSU with a mighty transformer, fast soft recovery diode-bridges and lots of paralleled, low esr capacitors before and after the regulators. That worked very well.
Now I consider to do the same just without the LM 1084. I am thinking, that there is a regulator onboard anyway- so- wouldn't building that way, give similar or even better results?
Is anyone experienced in this case?
Thanx!
Greetingz, Robert
I'm just about to start with my third Soekris DAM 1021 (rev.3)-build up. I used to power the board with an ultra solid linear regulated (LM 1084 ADJ) PSU with a mighty transformer, fast soft recovery diode-bridges and lots of paralleled, low esr capacitors before and after the regulators. That worked very well.
Now I consider to do the same just without the LM 1084. I am thinking, that there is a regulator onboard anyway- so- wouldn't building that way, give similar or even better results?
Is anyone experienced in this case?
Thanx!
Greetingz, Robert