Hi Borge,
I am going to get a replacement iPhone Lightning USB Camera Adapter
tomorrow and test some more. As for Windows and Linux, the tests
are still running with no apparent problems. Yay!
As for DSD, seems like you're going about it the hard way. I don't
think we need to do "native DSD", so there is no need to understand
the format of .dsf or .dff files. DoP (DSD over PCM) hides a lot of that
from us, and there is no DSD/PCM conversion anywhere, and no loss
of quality occurs.
Have you looked at the DoP specifications (it's very short. so won't take
long to read):
http://dsd-guide.com/dop-open-standard
Basically, it's the following:
1. The player software (such as foobar2000 or jriver) interprets the
DSD file and its data (via a plugin) wraps DSD data (with an 8-bit
special marker and 16 bits of data) into 24-bit PCM-like packets
and sends them down to the transport. Left and right channel
data are carried in separate interleaving packets. Single-rate
DSD (DSD64) is carried by PCM packets at 176.4KHz sampling rate.
(See the specifications about how double rate DSD128 or higher are
handled).
2. As far as audio drivers, USB audio hardware, etc., they don't know
that the stream is DSD. It looks like regular PCM to them.
3. On the receiver side (in our case, the audio widget), the firmware
needs to snoop the data in the input buffer (by looking for the
special markers) to detect whether the data is DSD wrapped in PCM rather
than real PCM.
4. If it is DSD, then the firmware takes 16-bit payload data from
the PCM packet and sent out via three lines (DSD-L, DSD-R and DSD-clock)
while flagging that this is a DSD stream by setting one of the GPIO pins
to cause some external logic on the analog board to route the above
to the appropriate pins on the DAC and set it to DSD mode.
5. That's pretty much it!
If possible, the DSD-L, DSD-R and DSD-clock signals can ride on the
same wires as the I2S lines used when in PCM mode. A very common
(but not universal) mapping on DACs is:
DSD_L -> LRCLK
DSD_R -> SDATA
DSD_clock -> SCLK
If the DAC isn't mapped this way, some routing logic can take care
of the differences.
As I posted before, I don't know if it's possible to make this mapping
on the audio widget. That's something need exploring but it's beyond my
knowledge as far as the AT32UC is concerned. Also I don't know the
code enough to know where to code the snooping of the special DSD markers
in the input buffer.
With the current widget implementation (max 192KHz PCM sampling rate),
we could support up to DSD128 (using method two with 176.4KHz, see
specifications). If Jaroslav's 384KHz sample rate support is stable
and incorporated into the main code, then we could support up to DSD256
(method 2 with 352.8KHz sample rate).
As for MQA, the closed aspect of it runs contrary to the open source
nature of audio widget, and that is enough to be a big red NO flag
for me. As far as I can tell, it doesn't offer anything over what's
already out there in PCM or DSD land, except it tries to get the recording
industry into the loop. I think it's more about getting large corporate
players to sign on and pay big royalty money, and less about sound
quality.
HDMI is also a closed system, and that's why you don't see any open
source or DIY project using it.
-Ti
On Fri, Feb 10, 2017 at 11:46:51AM +0100, Børge Strand-Bergesen wrote:
> Hi Ti,
>