Slaving audio board with MCK on the DAC via SPDIF

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
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.
 

Attachments

  • slave-spdif.png
    slave-spdif.png
    23 KB · Views: 798
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
 
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?
 
Member
Joined 2004
Paid Member
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.
 
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...8fd377fcfa91c0da8e6f0223f44209b26e7f6;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.
 
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
 
anbello said:
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.
 
Telstar said:


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.
 
anbello said:
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. :whazzat:

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... :xeye: :clown:

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. :dead:

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! :cannotbe:
 
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.
 
Why?

phofman said:
I actually tend to believe the sample rate "signalling" to the DAC could work.
{...}
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.

maybe, but I do not see the point to do that. Why should manually switching the sound card from external sync to the desired rate and then back again be more convenient that simply pressing a button on the "reclocker" card? :confused:
 
From UnixMan
please consider also 176.4 and 192.

Yes it's not difficult, it require switching from 8414/8404 to 8416/8406 and some thinking because they are not pin to pin compatible and have a different way of setting input output formats. Anyway from a quick overview of the 8416 datasheet i saw it's possible to set it slave with FSYNC and SCK input and SDATA output.

For the question of changing the FS on the DAC i think the best way is via a side channel (serial or usb) and a user space app, on linux an alsa plugin and on windows whatever a windows guy will do - i think will be simple, only some messages through a serial link.

Ciao
Andrea
 
Originally posted by anbello
from a quick overview of the 8416 datasheet i saw it's possible to set it slave with FSYNC and SCK input and SDATA output.

great.

BTW, I wonder: what will its internal ASRC do in that mode? will it be disabled?


For the question of changing the FS on the DAC i think the best way is via a side channel (serial or usb) and a user space app

yep. On windoze the easiest thing is to write a trivial "one-click" user-space app that simply does the (manual) rate-selection (for whatever it's worth).

Nevertheless, do NOT leave out manual rate-selection switches to be placed on the front panel of the "reclocker"... ;)

BTW: if you're going to implement such "remote-control" input, do not forget to use optocouplers there... or we can say good-bye to clean reclocking! :dead:

One more thing: it would be nice to have copper S/PDIF too. To keep the isolation, some transformers should be used there... or perhaps it would be better to build (or buy?) a copper->optical and an optical->copper S/PDIF converter?
 
phofman said:
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.

What i dont understand, is why it cant be a FPGA programmed to detect the samplerate *embedded* in the file. There isn't such kind of information in flac, wave and mp3 files? Any player that I have used show it.

Of course the switch in the soundcard mustn't be manual, it's should be done in software (the software player would change the switch).

But using a spdif out to a receiver just for this purpose can be accomplished.
 
Member
Joined 2004
Paid Member
If you look at what I had proposed its possible to add some relatively simple logic to have the system fully automatic and not needing a control line from the pc interface. Its a little involved so let me try to explain the concept.

First you need local low noise crystal oscillators at the dac (the reason for all of this) and divider chains at the dac to generate all of the necessary clocks for the target sample rates.
Then a means to send those to the PC interface, which should have a very high reverse loss to keep the PC from modulating the clocks.

The PC interface (ICE1724 type) is locked to the external clocks and works normally.

The crystal receiver chip works normally deriving the clock from the spdif/aes-ebu data stream.

Here is where the "magic" comes in. A phase comparator chain figures out which clock, if any, are the same as one of the 6 internal clocks (not real simple but possible with some simple logic) and switches to the correct local clock if there is a match. I think it could be done in less than 1 second.

The handoff should result in a reduction of jitter and better sound quality when it happens. Otherwise it should be imperceptible.

A few issues remain that need study. For example, the loop delay from clock to pc card and back may have the local clock far enough out of time with the detected clock to have setup timing issues. My (marginal) mental arithmetic says it must be less than 20 Ft. (20 nS) loop but I may be wrong on this.

It won't work with something like the Lynx or RME cards that use a PLL synthesizer to support any clock rate. And the card would need to be modified to support this. BUT it would work with multiple sources, even allowing the clocking scheme to work. I would make all of the clocks available from the DAC with multiple isolated interfaces so CD drives etc. that run at fixed rates can be locked.
 
Originally posted by Telstar
What i dont understand, is why it cant be a FPGA programmed to detect the samplerate *embedded* in the file. There isn't such kind of information in flac, wave and mp3 files? Any player that I have used show it.

because what gets out of the S/PDIF is NOT the encoded file, but just a stream of raw audio data (samples) without any header.

Actually, AFAIK that's not only what gets out of the sound card, but also what is being feed to it. The original file is decoded and converted by the player (and possibly re-processed by the driver, too) before being input to the sound card. Once it gets to there, all the information from the original file header(s) is lost.


Originally posted by Telstar
Of course the switch in the soundcard mustn't be manual, it's should be done in software (the software player would change the switch).

But using a spdif out to a receiver just for this purpose can be accomplished.

well, one may try to do as proposed by phofman. You'd have to tell the software (the player and/or the driver) to temporary switch the sound card clock to the internal one (at the right rate), wait until the reclocker detects the change on its input, change its own (master) clock accordingly and then switch back the sound card to "slave" mode.

This should be done before starting to play any new stream (or at least any new stream which have a different sample rate than the previously played one).

This is much MORE complicated to implement than the solution using a separated "signaling" line. Both for what concerns the hardware AND for what concerns the software. And (IMHO) it is also both awkward and failure-prone.

Nevertheless yes, possibly it can be done. But then again, WHY ???

just to avoid running a third cable from the PC to the reclocker?

and, in the end, all this just to avoid the need to press a button once in a while?

I simply wouldn't bother to do something cumbersome and overcomplicated just to avoid pressing a button once in a while. And that will likely be a looong while, too. How many DVD-audio do you have? how many audio files sampled at rates different from 44.1KHz?

Currently I have some 400GB of flac files (yet I have converted only a fraction of my CD collection). That is, several thousands of tracks. A few months of continuous playing time!

Of all these many files, only perhaps a handful are not coming from CDs. Even less are sampled at rates different from 44.1KHz. Why bother?

just because it can be done? coolness factor? :cannotbe:
 
Member
Joined 2004
Paid Member
The vast majority of music in digital is 44.1 and 16 bits but a lot of new interesting stuff is being issued in higher resolution higher data rate formats, so a way to support those is important I think. I know people who are using external word clock boxes and going through a ritual worth of playing vinyl to play a high res audio file. I don't think its necessary and this thread has illuminated several ways to resolve the issue. Commercialization is another story. . .

Full disclosure- I'm working on commercializing a linux based audio player without dac to address the above. I really don't want to make a dac product. I have done that before, not interested now. But the system and components for the pc side are what I'm working on. Not necessarily targeted at those here who could paste it all together themselves but for the rest of the niche interested in high res digital audio and unable to get a good solution that isn't a total kludge.
 
Originally posted by 1audio
First you need local low noise crystal oscillators at the dac (the reason for all of this) and divider chains at the dac to generate all of the necessary clocks for the target sample rates.
Then a means to send those to the PC interface, which should have a very high reverse loss to keep the PC from modulating the clocks.

Let' see... we'd need 44.1, 48, 88.2, 96, 176.4 and 192 KHz. So you have to send back to the sound card (at least) SIX different clocks. How would you send them back? six cables? :xeye: How would you connect all these clocks to the sound card??? :confused:



The PC interface (ICE1724 type) is locked to the external clocks and works normally.

it is locked to WHICH one of the 6 different clocks?! :confused:

How do you select the right one? :confused:
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.