I have four ASUS Essence STXii soundcards I would like to clock together. On my Linux machine.
Does anyone know of a good way to do that?
I've read that clocking can be achieved via SPDIF connections, the original STX had a SPDIF connector for connecting with video cards, it makes sense that if the STXii also has the same connector in the same place it does the same thing, and that it could be used for clocking...
https://www.overclockersclub.com/reviews/asus_xonar_essence_stx/2.htm
"The last two connectors on the card are a 4-pin "Molex" power connector and a S/PDIF header."
That's the best I've been able to find so far, anyone have any ideas?
Does anyone know of a good way to do that?
I've read that clocking can be achieved via SPDIF connections, the original STX had a SPDIF connector for connecting with video cards, it makes sense that if the STXii also has the same connector in the same place it does the same thing, and that it could be used for clocking...
https://www.overclockersclub.com/reviews/asus_xonar_essence_stx/2.htm
"The last two connectors on the card are a 4-pin "Molex" power connector and a S/PDIF header."
That's the best I've been able to find so far, anyone have any ideas?
Ad SPDIF sync - it would have to be SPDIF input and the controller would have to allow being clocked from the recovered SPDIF clock. ASUS Essence STXii has no SPDIF input, IIUC. For cards with SPDIF input see e.g. http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
Theoretically you can replace their crystals with a single external clock, like in https://github.com/markc/alsa/blob/master/lib/md/TwoCardsAsOne.md#Multiple_ice1712 https://web.archive.org/web/20100224154156/http://quicktoots.linuxaudio.org/toots/el-cheapo/ . IMO the single crystal may not feed all 4 cards properly, a real clock chip with buffered output may be necessary. But maybe it would work. In any case the chances of ruining your cards when removing the crystals soldered with high-temperature pb-free solder are quite high.
Even when the cards are made run synchronously, you still have to make sure they start the stream at exactly same moment. The multi plugin used for merging the cards calls the driver methods sequentially and there can be delays before the drivers do their job. But these delays may be sub ms.
Theoretically you can replace their crystals with a single external clock, like in https://github.com/markc/alsa/blob/master/lib/md/TwoCardsAsOne.md#Multiple_ice1712 https://web.archive.org/web/20100224154156/http://quicktoots.linuxaudio.org/toots/el-cheapo/ . IMO the single crystal may not feed all 4 cards properly, a real clock chip with buffered output may be necessary. But maybe it would work. In any case the chances of ruining your cards when removing the crystals soldered with high-temperature pb-free solder are quite high.
Even when the cards are made run synchronously, you still have to make sure they start the stream at exactly same moment. The multi plugin used for merging the cards calls the driver methods sequentially and there can be delays before the drivers do their job. But these delays may be sub ms.
I'm thinking a software based solution would work adequately.
The Brave Search AI suggested this:
aggregate device clock drift on a Linux system, you can follow these steps:
Identify the devices: First, you need to identify the devices that you want to aggregate. You can use the aplay -l command to list all the audio devices on your Linux system.
Create an aggregate device: Once you have identified the devices, you can create an aggregate device using the pacmd command. Here’s an example:
pacmd load-module module-combine-sink sink_name=aggregate
In this example, aggregate is the name of the new aggregate device.
Set the clock source: To set the clock source for the aggregate device, you can use the pactl command. Here’s an example:
pactl set-sink-clock-source aggregate alsa
In this example, alsa is the clock source for the aggregate device.
Enable drift correction: To enable drift correction for the devices in the aggregate device, you can use the pactl command. Here’s an example:
pactl set-sink-property aggregate drift-correction-factor 1.0
In this example, 1.0 is the drift correction factor.
Please note that the above steps are for a generic Linux system and might vary depending on the specific distribution and configuration. Also, the pacmd and pactl commands are part of the PulseAudio sound server, which might not be installed or configured on all Linux systems.
As for the Apple Support document, it refers to the Audio MIDI Setup utility on macOS, which is not available on Linux. However, the concept of clock drift and drift correction is similar across different systems.
The Brave Search AI suggested this:
aggregate device clock drift on a Linux system, you can follow these steps:
Identify the devices: First, you need to identify the devices that you want to aggregate. You can use the aplay -l command to list all the audio devices on your Linux system.
Create an aggregate device: Once you have identified the devices, you can create an aggregate device using the pacmd command. Here’s an example:
pacmd load-module module-combine-sink sink_name=aggregate
In this example, aggregate is the name of the new aggregate device.
Set the clock source: To set the clock source for the aggregate device, you can use the pactl command. Here’s an example:
pactl set-sink-clock-source aggregate alsa
In this example, alsa is the clock source for the aggregate device.
Enable drift correction: To enable drift correction for the devices in the aggregate device, you can use the pactl command. Here’s an example:
pactl set-sink-property aggregate drift-correction-factor 1.0
In this example, 1.0 is the drift correction factor.
Please note that the above steps are for a generic Linux system and might vary depending on the specific distribution and configuration. Also, the pacmd and pactl commands are part of the PulseAudio sound server, which might not be installed or configured on all Linux systems.
As for the Apple Support document, it refers to the Audio MIDI Setup utility on macOS, which is not available on Linux. However, the concept of clock drift and drift correction is similar across different systems.
That looks interesting, but I can't find this in any documentation. Do you have a link?
https://search.brave.com/search?q=aggregate+device+clock+drift+jack+linux&source=web
It's an AI response, you have to hit the "show more" button and wait for it to finish writing it.
It's an AI response, you have to hit the "show more" button and wait for it to finish writing it.
😂
Yes, and the answer always looks reasonable so it's really hard to tell when it's correct and when it's total nonsense.
I didn't read the whole thread, but you are talking about four Xonar Essence STX stereo cards, right?
I'm using the Xonar D2X 8-channel card. It has got four Ti/BB PCM1796 DAC-chips, and the C-Media CMI8788 as audio processor. I couldn't find the "clear name" of the AV100 of the STX, but it should be capable of 8-channels, too (as the STX does 8-channels with the daughterboard, and on that db are just 3 more dacs and the matching opamps). So the CMI8788 uses just one oscillator to deliver 4x2 I2S data streams.
Making this work for 4 stereo cards should not be impossible, or am I to naive?
I'm using the Xonar D2X 8-channel card. It has got four Ti/BB PCM1796 DAC-chips, and the C-Media CMI8788 as audio processor. I couldn't find the "clear name" of the AV100 of the STX, but it should be capable of 8-channels, too (as the STX does 8-channels with the daughterboard, and on that db are just 3 more dacs and the matching opamps). So the CMI8788 uses just one oscillator to deliver 4x2 I2S data streams.
Making this work for 4 stereo cards should not be impossible, or am I to naive?