Linux Audio the way to go!?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
UnixMan,

Thanks for sharing your experience. I played with tapping I2S from a CD player and hooking to an external DAC. 30cm of quality shielded CAT5 (the second wires in the pair grounded) without any proper impedance match, no buffers. The clock signal at the end did not look good on my scope. And I could tell it from the sound.

I love the shielded CAT5 cable (STP), inexpensive and very universal. E.g. my S-VIDEO cable is 12 meters long - crisp sharp picture.
 
UnixMan said:
Hi phofman,

Nonetheless, to get the most out of it obviously I need to build an I2S level shifter + buffer. I wonder: has anybody done a circuit like that before and is willing to share it?

I'm not sure there's much magic to it. My delta 1010 uses 74ac245 buffers to transmit 8 in/8 out I2S over a ~10' DB25 cable. Not that this is optimal either, but it works. I'm not sure about the level shift - I know John Swenson used 74xx logic to go the other way since it's 5V tolerant when running at 3.3, but I don't know if it works the other way around.

It's interesting that there are a few folks doing external I2S. I'm working on a project using my Delta 1010 card to feed the I2S externally. I'm 'planning' on trying to do a reclock arrangement based on Swensons squeezebox reclock, and have most of the parts except the clock (can't find a 22.57xx clock, and I was planning on doing 44/88 first). For isolation, I got some of these http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=390-1116-5-ND to try out. I'll be hooking this up to a TAS5518 evm module (since a pll is used in the 5518 internally, I suspect there's a limit as to how far improving jitter will help, but it's worth trying)

I'm expecting that the reclock and the galvanic isolation should pretty much remove the PC from the equation, but this is still speculation.
 
dwk123 said:

It's interesting that there are a few folks doing external I2S.

Yup, you're not the only one :)

dwk123 said:

I'm working on a project using my Delta 1010 card to feed the I2S externally. I'm 'planning' on trying to do a reclock arrangement based on Swensons squeezebox reclock, and have most of the parts except the clock (can't find a 22.57xx clock, and I was planning on doing 44/88 first). For isolation, I got some of these http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=390-1116-5-ND to try out. I'll be hooking this up to a TAS5518 evm module (since a pll is used in the 5518 internally, I suspect there's a limit as to how far improving jitter will help, but it's worth trying)

I'm expecting that the reclock and the galvanic isolation should pretty much remove the PC from the equation, but this is still speculation.

The isolators are very interesting. Where are you going to put them? In the 1010 or at the input of the DAC?

The best solution for jitter is to slave the transport to the DAC and to not use any kind of receiver nor ASRC there.
That is what I'm pursuing. On the computer part, I'm using an Infrasonic Quartet (not modded yet), which is excellent and most important, has a wordclock input.

I was going to ask in this thread if there are already linux drivers, IIRC they were working on them.
 
Infrasonic Quartet is a nice card indeed. Since the card's manufacturer SIMS Corp. is interested in full linux support, they helpfully provided me with a sample and some key information. I am working on the alsa driver, it will take a few days though :) And good to have someone around to test the result :)
 
phofman said:
Infrasonic Quartet is a nice card indeed. Since the card's manufacturer SIMS Corp. is interested in full linux support, they helpfully provided me with a sample and some key information. I am working on the alsa driver, it will take a few days though :) And good to have someone around to test the result :)

I have to thank you for pointing it to me :)
I got it yesterday and I'm very pleased (running vista)

If you have some more technical information or a mail of somebody over there, can you drop me an email? I wonder if the "I.S.D. link" has already i2s pins inside. That would mean that no mod on the card is needed to tap i2s (too good to be true but maybe...)
 
Originally posted by Telstar

That is what I'm pursuing.

mee too, eventually. :smash:


On the computer part, I'm using an Infrasonic Quartet (not modded yet), which is excellent and most important, has a wordclock input.

A card which have a dedicated wordclock input of course makes thing simpler, but it's not really required! What we'd like to do can be done also with a simpler/cheaper/more common/better supported card which does not have such input.

Just about any decent (full-duplex) card which have at least one S/PDIF input (including my Juli@, of course... :cannotbe: ) 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... :cannotbe:
 
Telstar said:


Yup, you're not the only one :)


Well, my slight surprise wasn't that there are folks doing it, more that they seem to be concentrated in the LInux area.


The isolators are very interesting. Where are you going to put them? In the 1010 or at the input of the DAC?
My plan is to put 'everything' in the DAC (really the amp, since the TAS5518 evm is both). I haven't determined whether the delta 1010 cable carries +5V though, which is needed for the isolators. Running a separate line isn't that hard, but it'd be so easy if the signal came in on the same cable.

The best solution for jitter is to slave the transport to the DAC and to not use any kind of receiver nor ASRC there.
Well, if it wasn't clear that's exactly what I'm doing. The clock will be fed back to the 1010 pci card as JohnR did here:

http://sound-man.co.uk/interface.html
It requires replacing the onboard crystals with a feed from the clock, but it appears to work fine. I'm just frustrated by the lack of 44/88 clock modules around. Any pointers to sources is welcome. I'm looking at 88 rather than 96 since
a) easier upsampling for redbook
b) still planning to mod the Oppo for 88k pcm output from sacd
c) recording vinyl (if I ever get to it) shouldn't care, so 88k is fine.

I'll go with 96 if I can't find a decent clock, but I'm holding out hope.

For reference, Swenson's reclock scheme is here:
http://forums.slimdevices.com/showthread.php?p=191045&highlight=pico#post191045

Since everything is I2S in my case, I don't need the added complexity of the LJ->I2S delay portion, so it basically boils down to a 74174 and a 7474.

That is what I'm pursuing. On the computer part, I'm using an Infrasonic Quartet (not modded yet), which is excellent and most important, has a wordclock input.

Interesting. The specs on the Infrasonic site actually indicate that it will accept a 256*fs clock directly over the BNC. That's cool - no need for mods or spdif sync etc. How easy is it to get I2S off this card?
 
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 build 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.

Ciao
Andrea
 

Attachments

  • slave-spdif.png
    slave-spdif.png
    16 KB · Views: 461
UnixMan said:

Just about any decent (full-duplex) card which have at least one S/PDIF input (including my Juli@, of course... :cannotbe: ) 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.

Yes, you are correct of course.

But since the Quartet costs the same as the Juli@ (in Italy) and I like simple things... ;)
Also, I dunno how simple is in the DAC to have a spdif out. I will get the wordclock out from the master clock.

PS: I'm talking about a DAC without without spdif altogether :D
 
Member
Joined 2004
Paid Member
UnixMan:
Can you post the pinout of the connection on the Juli@ card (since you seem to have figured it out)?

With the active assistance of Max (of MPD) we now have seemingly flawless bit perfect playback of HRx files from MPD. This is best verified with the BADA dac and its HDCD light verifying "bit-perfect" playback of 176.4 KHz files. The current MPD git works right and seems to be identical to playing directly from aplay sonically. As for the need for other features or mixing etc, for my purposes they are un-necessary. And the Juli@ card has separate crystal chains for 44.1 and 48 multiples making for lower jitter than most PLL's can achieve. Next step is creating external low phase noise clocks for the Juli@ card.

Originating the clock at the DAC is the right way but there is a bootstrap problem- the source needs to tell the dac what sample rate for the dac to switch the clocks, however there is no mechanism to do that in current products.

With good shielding the soundcard should be a good digital source especially if noise impact on the clocks and output connections are minimized. The spdif/aes-ebu output transformer is very important for this as is optimized impedance matching- reflections will cause a lot of data dependent jitter in the signal.

My biggest concern is that there isn't much happening in new soundcard chipset options that support all 6 sample rates. I hope Via will continue the Envy24 series. The others don't look as good and the Lynx /RME stuff has a whole lot of baggage not needed for 2 channel playback.
 
1audio said:
Originating the clock at the DAC is the right way but there is a bootstrap problem- the source needs to tell the dac what sample rate for the dac to switch the clocks, however there is no mechanism to do that in current products.

Yes, this is a major issue. It is possible to provide sample rate/volume support via serial port/I2C/ethernet (as an alsa-lib plugin or directly in the driver). E.g. there is a great alsa-lib plugin controling Arcam AVR via serial port (volume, balance, etc.). But there are no DACs supporting this.


1audio said:
With good shielding the soundcard should be a good digital source especially if noise impact on the clocks and output connections are minimized.

That is exactly the goal of my little project - a low-power network player with any quality PCI card physically separated from the little mainboard.

1audio said:
My biggest concern is that there isn't much happening in new soundcard chipset options that support all 6 sample rates. I hope Via will continue the Envy24 series. The others don't look as good and the Lynx /RME stuff has a whole lot of baggage not needed for 2 channel playback.

Yup, this is sad. I have yet to see a PCI express chip with both crystals. IIRC, there are some new PCIe cards with Envy24 and PCIe-PCI bridge. The 44.1kHz family is a matter of past and I am afraid manufacturers are not planning to mass produce PCIe pro-sumer cards with crystal 44.1kHz clock anymore. The PCI slot is a matter of past too, one must admire the bravery of Infrasonic (SIMS Corp.) to develop and market a brand-new PCI card these days.
 
phofman said:

Yup, this is sad. I have yet to see a PCI express chip with both crystals. IIRC, there are some new PCIe cards with Envy24 and PCIe-PCI bridge. The 44.1kHz family is a matter of past and I am afraid manufacturers are not planning to mass produce PCIe pro-sumer cards with crystal 44.1kHz clock anymore.

Besides being future-proof, I'm not sure anymore of the superiority of PCI for audio applications.
See here:
http://www.audioasylum.com/forums/pcaudio/messages/4/47769.html

The PCI slot is a matter of past too, one must admire the bravery of Infrasonic (SIMS Corp.) to develop and market a brand-new PCI card these days.

It isn't so new. Auzentech got US distribution recently, but the Quartet has already been on the market for 3 years. I actually asked Auzentech if they are planning a pci-e version of the Quartet but got no reply (so far).
 
1audio said:
Originating the clock at the DAC is the right way but there is a bootstrap problem- the source needs to tell the dac what sample rate for the dac to switch the clocks, however there is no mechanism to do that in current products.

A FPGA in the DAC should be able to detect the sample rate being served through spdif or i2s. And the DAC should slave the soundcard to itself.

How does these drivers look? ;)
 

Attachments

  • cp1.png
    cp1.png
    34.6 KB · Views: 366
Telstar said:
Besides being future-proof, I'm not sure anymore of the superiority of PCI for audio applications.
See here:
http://www.audioasylum.com/forums/pcaudio/messages/4/47769.html

Oh, again the story of low latency needed for quality playback. Yes low latency needed for MIDI/monitoring/mastering. Not so for pure playback. In fact the oposite - high latency - reduces interrupts, CPU load, danger of xruns, as the card reads larger chunks of data independantly without "bothering" the CPU.

In fact, I do not care much about the technology transmitting data between memory and I2S/whatever-format generator, as long as it provides sufficient reliable throughput, asynchronous feedback for flow control, the card features separate crystal clocks, and linux has reliable open source drivers for the key functions. It could as well be USB/FW, but still PCI cards seem to provide the best price/quality/performance ratio to me.


Telstar said:
It isn't so new. Auzentech got US distribution recently, but the Quartet has already been on the market for 3 years. I actually asked Auzentech if they are planning a pci-e version of the Quartet but got no reply (so far).

Thanks for the info, I did not know that.
 
Telstar said:
A FPGA in the DAC should be able to detect the sample rate being served through spdif or i2s. And the DAC should slave the soundcard to itself.

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.
 
Sorry just the last post a little bit OT.
Maybe not too much OT - i'am speaking of a linux box attached to an external dac with an spdif interface capable to slave the audio board in the box and so with the master clock on the dac.
What do you thing of the solution proposed on post #988?
Is it not interesting to you or not enough well explained?

If someone is interested i can open a new thread to talk about this stuff.

Ciao
Andrea
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.