pushing a button on a box doesn't look to me like such a complex "ritual"...
( ...besides, most audiophiles do like rituals!
)That said, I'm looking forward to understand your idea. Undoubtly it sounds cool.
Though for myself I would rather use a simpler solution which does not imply using any specific sound card (let alone modifying it).
this sounds cool too! Good Luck!
The ICE1724 uses two local crystals- the Juli@ implementation has a 22 MHz and a 24 MHz crystal. Those are what would be in the DAC and sent back to the PC interface. The PC interface has its own clock chain off of those. These are sometimes called superclocks (256 X fs I think) and used for locking multiple devices in pro audio applications.
Both clocks are always live in the PC interface and it selects locally which one to use. That's the reason for the duplicated clock chain in the dac and the detection circuit to determine which clock to use locally.
There are legitimate reasons for having as much isolation from the pc and the dac as possible, since the PC is full of things with unrelated clocks.
Both clocks are always live in the PC interface and it selects locally which one to use. That's the reason for the duplicated clock chain in the dac and the detection circuit to determine which clock to use locally.
There are legitimate reasons for having as much isolation from the pc and the dac as possible, since the PC is full of things with unrelated clocks.
The "ritual" is more involved of course, since you need to cue the audio track, make sure you have selected the right clock rate, selected external word clock (which requires a PLL in the sound card to lock to the external clock, a compromise I think) and start play. Switch to a different song from a different label at a different rate and hope you got it all right. There is enough voodoo to and poorly understood digital technology to keep the worshipers in line. The typical setup can cost $10K-15K so it must be good.
I hope to shine a bright light on some of this with what I'm doing.
I hope to shine a bright light on some of this with what I'm doing.
I' am happy that this thread has generated so much discussion on this stuff of reclocking and slaving the audio card on the PC. But it seems to me that someone is going a little bit OT (this is not a problem, more food for mind). I started this thread to discuss about an interface that has the MCK (free running XO), from this generate FSYNC and SCK to feed the DAC with low jitter timings and a blank spdif signal to slave the audio card (which has to be set to lock on external clock).
I built a prototype from the schematics on the first post and it works, now i would like to improve this following some of the hints you give me.
If someone propose something different from what i have outlined i would like to see some form of schematics or sketch in such a way that is possible to built and try it (we are on diyaudio).
Ciao
Andrea
I built a prototype from the schematics on the first post and it works, now i would like to improve this following some of the hints you give me.
If someone propose something different from what i have outlined i would like to see some form of schematics or sketch in such a way that is possible to built and try it (we are on diyaudio).
Ciao
Andrea
It took me a few days to realize Telstar has been right from the very begining. SPDIF stream in professional mode can carry the sample rate information in its preamble. At least the linux ice1724 driver puts the info into the stream, see http://git.alsa-project.org/?p=alsa...a785344886cf6d3207b244850ed6245;hb=HEAD#l1110 .
Decent SPDIF receivers recover these fields and make them available, see e.g. page 15 of http://data.eeworld.com.cn/pdf/2300_AKM_AK4114.pdf.
Some cards are able to detect sample rate of the incoming external clock and it is up to their drivers what they do with the information. Juli's alsa driver uses the detected sample rate only when recording from SPDIF input (capture_substream). I do not think any alsa driver sets the outgoing SPDIF preamble according to the incoming external clock rate, they always put the rate of the audio stream played.
Therefore, it is possible to signal the current song rate to the DAC while running on the external clock, and the DAC can change the master clock accordingly.
I have not tested if windows drivers set the preamble, but I would assume they do. It is possible to check when feeding the tested SPDIF stream into linux - juli's ak4114 registers are available via /proc and their bits can be easily checked against the datasheet.
Decent SPDIF receivers recover these fields and make them available, see e.g. page 15 of http://data.eeworld.com.cn/pdf/2300_AKM_AK4114.pdf.
Some cards are able to detect sample rate of the incoming external clock and it is up to their drivers what they do with the information. Juli's alsa driver uses the detected sample rate only when recording from SPDIF input (capture_substream). I do not think any alsa driver sets the outgoing SPDIF preamble according to the incoming external clock rate, they always put the rate of the audio stream played.
Therefore, it is possible to signal the current song rate to the DAC while running on the external clock, and the DAC can change the master clock accordingly.
I have not tested if windows drivers set the preamble, but I would assume they do. It is possible to check when feeding the tested SPDIF stream into linux - juli's ak4114 registers are available via /proc and their bits can be easily checked against the datasheet.
phofman said:
Instead i think that it's what any alsa driver of Envy24* based cards do when you set the "Multi Track Internal Clock" to [IEC958 Input] that is what is needed for the "mechanism" of slaving to work.
The played audio stream has the rate of incoming blank spdif signal used to have all in synch.
Ciao
Andrea
phofman said:
OK i see, in this Technote by Julian Dunn a really good introduction on the Digital Interface both consumer and professional, on pages 6-9 explanation of channel status bits.
What i don't know is if you can send a stream at a certain sampling frequency with another sampling frequency encoded in the channel status bits, or i misunderstood what did you intend?
Ciao
Andrea
IEC60958 sample rate status
IEC60958
Unfortunately only 44.1, 48, 32(!!) and 96 are defined and even then only last year in the AES05 standard. Furthermore the professional standard uses different bits for the sample rate indications from the consumer standard. Standards are wonderful- there are sooo many to chose from. I'm not ready to spend $50 for a copy of the latest so I'll see if I can get a current AES member to get it for me for the $5 price.
One of the options is "not indicated" which would not be helpful.
I don't think it will solve the problem we are discussing. I'll see if I can check on the real data stream what is coming out.
IEC60958
Unfortunately only 44.1, 48, 32(!!) and 96 are defined and even then only last year in the AES05 standard. Furthermore the professional standard uses different bits for the sample rate indications from the consumer standard. Standards are wonderful- there are sooo many to chose from. I'm not ready to spend $50 for a copy of the latest so I'll see if I can get a current AES member to get it for me for the $5 price.
One of the options is "not indicated" which would not be helpful.
I don't think it will solve the problem we are discussing. I'll see if I can check on the real data stream what is coming out.
1audio,
channel status bits are set by SPDIF transmitter and are physically independent of the actual sampling rate. If you have a transmitter which gives you control over its registers, you can set anything you want to.
The SPDIF receiver AK4114 datasheet I gave a link for lists the correct values, you do not have to buy any documentation. Envy24 (ice1712/24) enables you to set the channel status bits in its integrated SPDIF register, see page 55 of http://alsa.cybermirror.org/manuals/icensemble/Envy24HT091DS.pdf , register MT3C:
It says that if the chip runs from external clock, the driver is responsible for setting correct value (since the chip itself does not know the current sample rate when running from external clock - slave mode). And the link for alsa ice1724 driver in my previous post shows the driver does this task correctly. Windows driver can be checked for this functionality, see my posts above.
channel status bits are set by SPDIF transmitter and are physically independent of the actual sampling rate. If you have a transmitter which gives you control over its registers, you can set anything you want to.
The SPDIF receiver AK4114 datasheet I gave a link for lists the correct values, you do not have to buy any documentation. Envy24 (ice1712/24) enables you to set the channel status bits in its integrated SPDIF register, see page 55 of http://alsa.cybermirror.org/manuals/icensemble/Envy24HT091DS.pdf , register MT3C:
It says that if the chip runs from external clock, the driver is responsible for setting correct value (since the chip itself does not know the current sample rate when running from external clock - slave mode). And the link for alsa ice1724 driver in my previous post shows the driver does this task correctly. Windows driver can be checked for this functionality, see my posts above.
If the chip is set for external clock and is syncronizing with a word clock or spdif input it must then internally generate a bit clock. That would require a local pll. The real question coming from this is whether the jitter on the incoming data would influence the internals of the dac and how much. It looks like it would work. You still need clock chains in the dac for both families of sample rates. And some logic to enable the system to work when the source isn't locked.
It seems that an ICE1724 based soundcard in a linux system could implement the PC side of this pretty easily. What happens if the word clock isn't present when you engage external clocking?
It seems that an ICE1724 based soundcard in a linux system could implement the PC side of this pretty easily. What happens if the word clock isn't present when you engage external clocking?
Demian,
I see yo're still interested in this - any progress on the Linux audio player idea?
I guess a fanless M/b with PCI to accept a Terratec Aureon 7.1 Space soundcard is about the best solution then or is it? It's difficult to find these soundcards though.
Edit: I'm also only interested in 96KHz as I don't have any 176KHz audio or am likely to be getting any (by the time this is widely available I'm sure there will be a better audio solution, anyway). So I believe trying to go above 96KHz just complicates everything & makes achieving anything worthwhile more difficult
I see yo're still interested in this - any progress on the Linux audio player idea?
I guess a fanless M/b with PCI to accept a Terratec Aureon 7.1 Space soundcard is about the best solution then or is it? It's difficult to find these soundcards though.
Edit: I'm also only interested in 96KHz as I don't have any 176KHz audio or am likely to be getting any (by the time this is widely available I'm sure there will be a better audio solution, anyway). So I believe trying to go above 96KHz just complicates everything & makes achieving anything worthwhile more difficult
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.