Slaving audio board with MCK on the DAC via SPDIF

[anbello]

A fork from the thread "Linux Audio the way to go!?"

From UnixMan's post #986

Just about any decent (full-duplex) card which have at least one S/PDIF input (including my Juli@, of course... ) can be synchronized to it. All you need to do is to embed your DAC local clock into a dummy s/pdif stream and sent that back to the sound card input. You lock the card to it and bingo!, your output stream is locked to the local clock on your DAC. Just open up the connection between the s/pdif receiver reconstructed clock and your DAC (connect it directly to the local clock) and you're done. In principle it's trivial...

it's what i did with my TerraTec Aureon 7.1 Space (Envy24HT based) and the attached circuit. I built a prototype of this circuit on perfoboard using 78l05 for any +5V* point in the schematic and toslink input output. The cs8402 (in mode 0) generate a blank spdif signal to sync the audio board and the right FSYNC and SCK to feed the cs8414 (slave in mode 3). The cs8414 receive the spdif signal from the audio board and output i2s. This i2s is then reclocked from the same clock that control the cs8402.
From alsamixer i choose IEC958 Input as the source for the 'Multi Track Internal Clock'.
It works.

[anbello]

The prototype described on previous post is attached to the TerraTec Aureon 7.1 Space (i think any envy24* based card it's OK) with two optical cables (one to spdif in and one from spdif out) to have complete galvanic isolation. For now i'am using it with a DIY DAC with 4 TDA1543 (not so good and not so bad) using for I2S connector a SIL header on the two boards and short twisted pair.
I'am searching SIL male and female angled connector to attach the two boards close to each other.

The next steps are:
1) improve this circuit: better ps; better digital signal interfacing (some resistors from chip to chip and some kind of buffer/driver for the MCK and maybe for the other I2S signal); two clocks (11.2896 and 12.288) and the possibility to choose from 4 FS (44.1, 48, 88.2, 96KHz)
2) design a good PCB layout
3) build more DAC modules with other DAC i have (PCM1794A, AK4396, AD1955)

I'am open to hints and critics

Ciao
Andrea

[Telstar]

Related to this is my work with the Infrasonic Quartet board.

If the card is slaved to the DAC, its output sample rate will correspond to the incoming clock from the DAC.
The DAC clock must be changed first for the whole chain to move to another sample rate.

Would a buffer be enough to let the FPGA in the DAC recognize the sample rate?

Alas, i2s sends a clock, could that be used?

[1audio]

It would be possible to make a circuit that could sense and switch clocks however there is a core bootstrap problem. Alsa knows the sample rate (usually. . .) and communicates it to the driver and the hardware. But the hardware has no standard way to communicate that downstream except the clock in the data stream. If the clock for the data stream comes from the remote source somehow the clock needs to be switched remotely.

its possible to have the two master clocks at the DAC and send them back to the card in the PC, further using some tricks at the receiver chip to select which clock to use locally. The logic would not be too difficult to implement but it would be unique to the specific system since its not at all standardized. It would allow a standard spdif/ aes-ebu link, but also requires two reverse clock links if the card is capable. The Juli@ card could do this and is unique in ICE1724 cards in its ability to handle 176.4 sample rates I'm told. It would be a lot of surgery to accomplish. Further, reclocking at the output of the card to clean up the data and reduce sideband noises would not be possible because of the bootstrap issue.

There may be a GPIO pin on the ICE1724 that indicates the sample rate in use but I could not find one listed here . We may be able to hijack a gpio for this and get the Linux driver revised to support it. Not simple but the guy who wrote the Juli@ driver for Linux has been very helpful.

[phofman]

If you want to have the primary clock in the DAC and feed it backward to the slaved card, your only reasonable option for changing the sample rate is to switch the primary clock in the DAC.

All you need to do is to control the DAC clock circuit from your PC somehow. Linux provides limitless options, just pick the one fitting your needs best.

GPIOs of Envy are easily controllable from the driver (which always knows current fs), tapping a few of them and feeding to the DAC is one option. Envy24 offers I2C driver too, many codecs use it - another option.

Still, I would prefer using a standard communication solution, such as the serial or parallel port. Writing a user-space alsa pass-through plugin communicating the current sample rate upon change via these channels should not be difficult. For inspiration, check out the amazing Arcam AV plugin http://git.alsa-project.org/?p=alsa-...26e7f6;hb=HEAD

All you can do with Envy in external clock mode is to run it at twice the incoming sample rate. I did that when I was trying to compare my CD player output for original and copied CD-DA. I hooked the 44.1kHz SPDIF output of the player to SPDIF-IN, switched the card to external clock, and mangled Envy24 registers to run the card (i.e. the ADC) at 88.2kHz. This way I sampled the CD player analog output always at the same instance (to be able to compare the waves sample by sample) while running at 88.2kHz to provide higher-quality sampling. But that is not about controlling the primary DAC clock.

[anbello]

Thanks to phofman and 1audio to have answered to Telstar, i think the better option to control the DAC clock from the PC is via a serial or usb (with ft232 for usb <=> serial) link as oulined by phoman and, yes, the alsa arcam-av plugin is a good starting point.
On the board a max232 or ft232 and a pic could be added to receive messages from the PC and select the right clock and, eventually, return messages with status.

Ciao
Andrea

[Telstar]

Originally posted by anbello
Thanks to phofman and 1audio to have answered to Telstar, i think the better option to control the DAC clock from the PC is via a serial or usb (with ft232 for usb <=> serial) link as oulined by phoman and, yes, the alsa arcam-av plugin is a good starting point.

FYI, I do not want the DAC clock to be controlled by software. I have a FPGA logic in my DAC and I want to use that to recognize the incoming sample rate and perform the required operations (that is, i2s-> right align conversion, crystal and divider selection and to send the appropriate wordclock to the sound card).

Besides, it has to work also under Windows.

[phofman]

Originally posted by Telstar


FYI, I do not want the DAC clock to be controlled by software. I have a FPGA logic in my DAC and I want to use that to recognize the incoming sample rate and perform the required operations (that is, i2s-> right align conversion, crystal and divider selection and to send the appropriate wordclock to the sound card).

Besides, it has to work also under Windows.

There is a way, though a bit clumsy:

1) The card running in internal mode, initially switched to e.g. 32kHz

2) The card's internal fs changed to the required fs, e.g. 44.1kHz

3) DAC detects fs change, and reconfigures its clock to this fs.

4) Switch the card to external clock mode, start playback

5) If you want to change fs, switch the card to internal mode, change fs, wait for the DAC until it detects the change and recofigures its clock

6) Switch the card to external clock mode, start playback


Prerequisite for this sequence is that your DAC can detect fs change and reconfigure its clock accordingly. You can start playback before switching the card to external clock but most likely you will hear a click when switching afterwards. That is easy to test already now.

By DAC I mean the SPDIF receiver.

[UnixMan]

Originally posted by anbello
two clocks (11.2896 and 12.288) and the possibility to choose from 4 FS (44.1, 48, 88.2, 96KHz)

please consider also 176.4 and 192.

Originally posted by Telstar

FYI, I do not want the DAC clock to be controlled by software. I have a FPGA logic in my DAC and I want to use that to recognize the incoming sample rate and perform the required operations (that is, i2s-> right align conversion, crystal and divider selection and to send the appropriate wordclock to the sound card).

well, that would be nice... but -as said by 1audio- I'm afraid it can't be done.

We have a "chicken and egg" problem here: if the sound card is slaved to an incoming stream it is clocked by that and works at that very same rate. That is, in our case, the rate of our external "master clock".

In turn our "reclocker" receives (and MUST receive) its input stream synchronized to (and at the very same rate of) its own "master" clock.

This holds true whatever is the actual (original, "right") sampling rate of the stream being played. Playing another stream which was sampled at a different rate will NOT cause the sound card to change its output rate!

If you're using some "smart" mode (e.g. ALSA "plughw" device), the driver will resample (upsample or downsample) in software the new stream to whatever is the current "master clock" rate before sending it to the sound card.

If you send the "raw", unprocessed stream to the sound card instead, again the card will play it at the rate dictated by the external clock. Of course, if the stream being played was sampled at the different rate, you'll simply get the wrong rate and strange sounds will come out...

AFAIK, once the stream gets out of the sound card there is no way to know which was its "right" (original) sample rate. Thus there is no way for your FPGA to detect it and act accordingly (am I wrong?).

If I'm not wrong, then the only thing you can do to change the sample rate of the whole chain is changing the master clock (on the external board).

Obviously the simplest, easiest way to do it is manually, e.g. using some switch on the "reclocker" board whenever we play some material sampled at a different rate than the previous one(s).

{given that 99.99% of the available music is still sampled at 44.1KHz only, for me that would not be such a big issue...}

A more advanced (but complex) possibility is the proposed solution of "automatically remote controlling" the master clock from the PC. That is, you'll have to sense (in software) the "right" (original) sampling rate of what you're playing and switch the master clock accordingly via some simple dedicated connection (e.g. serial line, etc).

Again as said, on Linux this can be done (relatively "easily") at the driver level, so that it will work for whatever audio source (audio, A/V, etc) and player used.

On windoze I'm afraid that would be much harder (if at all possible) to do.

The only easy (?) solution that I can think about is application-specific: that is, to write a plugin for "foobar" which gets the stream rate and does the remote clock-switching accordingly.

Otherwise, if you do not want to bother switching sample rates by hand and do not want the complication of software controlling the master clock either, there is a third alternative: keep the master clock at the DAC's highest supported rate (e.g. 176.4 or 192KHz) and let the PC always resample in software to that.

Of course that is not a "bit-perfect" solution. Nevertheless, using a decent resampling algorithm it is not necessarily bad sound-wise. It may even turn out that some DACs will sound better that way!

[phofman]

I actually tend to believe the sample rate "signalling" to the DAC could work. Decent SPDIF receivers with auxiliary fixed-frequency clock detect the incoming rate reliably, and it would not be difficult to check the rate several times a second for change and switch the main DAC clock to follow the incoming rate. The "act of synchronization" would require only switching the card manually to internal clock set to the required rate and back to external clock - easily doable in windows too.

Of course the control link to DAC is a much cleaner solution, but the windows requirement kills most options.