[alsa-devel] Enabling in-kernel synch for M-Audio boards
Hello all!
I'm developing a complex multichannel audio distribution system where multiple linux boxes will stream audio data over ethernet and then should play audio at sample level resolution synchronization. The boxes clocks are synchronized over ethernet using PTP. I need to keep in synch the audio board's clocks and I can't use an external wordclock nor s/pdif.
At the moment I'm experimenting with m-audio delta 1010, based on envy24 (VT1712). I know these boards can synch their clocks over PCI signalling (in windows drivers this feature support synching up to 4 boards), but ALSA drivers don't implement that feature. I'm trying to implement a similar feature (controlling board clock synch through kernel module), but it's very difficult without a good starting point! Is there anyone that could give me some help, support or infos? I would eventually appreciate also hardware reference designs or application notes about the VIA envy24 VT1712 chip.
Obviously, should I ever be successful in the implementation, those features could be eventually added to ALSA drivers.
Thank you all in advance.
Regards,
Ludovico
On Mon, Sep 17, 2007 at 12:22:19PM +0200, Ludovico Verducci wrote:
Hello all!
I'm developing a complex multichannel audio distribution system where multiple linux boxes will stream audio data over ethernet and then should play audio at sample level resolution synchronization. The boxes clocks are synchronized over ethernet using PTP. I need to keep in synch the audio board's clocks and I can't use an external wordclock nor s/pdif.
Won't this cause serious clock jitter problems? I don't see how the PCI bus can deliver precise enough timing, considering how much other data it has to handle.
John
On Mon, Sep 17, 2007 at 08:44:03PM +0100, John Rigg wrote:
On Mon, Sep 17, 2007 at 12:22:19PM +0200, Ludovico Verducci wrote:
Hello all!
I'm developing a complex multichannel audio distribution system where multiple linux boxes will stream audio data over ethernet and then should play audio at sample level resolution synchronization. The boxes clocks are synchronized over ethernet using PTP. I need to keep in synch the audio board's clocks and I can't use an external wordclock nor s/pdif.
Won't this cause serious clock jitter problems? I don't see how the PCI bus can deliver precise enough timing, considering how much other data it has to handle.
And I can't see any way that the clocks can be synced to sample accuracy over ethernet. That's what external word clocks are for. Even with a word clock I suspect that the latency of the ethernet connection would be too high to allow sample accurate sync of the audio.
John
John Rigg ha scritto:
On Mon, Sep 17, 2007 at 08:44:03PM +0100, John Rigg wrote:
On Mon, Sep 17, 2007 at 12:22:19PM +0200, Ludovico Verducci wrote:
Hello all!
I'm developing a complex multichannel audio distribution system where multiple linux boxes will stream audio data over ethernet and then should play audio at sample level resolution synchronization. The boxes clocks are synchronized over ethernet using PTP. I need to keep in synch the audio board's clocks and I can't use an external wordclock nor s/pdif.
Won't this cause serious clock jitter problems? I don't see how the PCI bus can deliver precise enough timing, considering how much other data it has to handle.
I didn't mean to directly drive the audio board's clock over the PCI bus. I think this is simply not feasible. But I think that using control signals periodically exchanged over PCI between the audio board and the kernel could be possible (if the hardware could support a similar feature, of course) to skew the board's clock to keep it in synch with a software reference. As far as I know the delta family boards drivers support the synchronization of up to 4 audio boards over PCI: at the moment I'm reverse engineering the hardware trying to understand how this can be accomplished.
And I can't see any way that the clocks can be synced to sample accuracy over ethernet. That's what external word clocks are for. Even with a word clock I suspect that the latency of the ethernet connection would be too high to allow sample accurate sync of the audio.
John
The machines real time clocks are synched over ethernet using Precision Time Protocol. This protocol can achieve below 1 microsecond synchronization accuracy. This should be fine to sample level synch at 48 KHz.
Regards,
Ludovico
On Tue, Sep 18, 2007 at 10:07:05AM +0200, Ludovico Verducci wrote:
John Rigg ha scritto:
On Mon, Sep 17, 2007 at 08:44:03PM +0100, John Rigg wrote:
On Mon, Sep 17, 2007 at 12:22:19PM +0200, Ludovico Verducci wrote:
I'm developing a complex multichannel audio distribution system where multiple linux boxes will stream audio data over ethernet and then should play audio at sample level resolution synchronization. The boxes clocks are synchronized over ethernet using PTP. I need to keep in synch the audio board's clocks and I can't use an external wordclock nor s/pdif.
Won't this cause serious clock jitter problems? I don't see how the PCI bus can deliver precise enough timing, considering how much other data it has to handle.
I didn't mean to directly drive the audio board's clock over the PCI bus. I think this is simply not feasible. But I think that using control signals periodically exchanged over PCI between the audio board and the kernel could be possible (if the hardware could support a similar feature, of course) to skew the board's clock to keep it in synch with a software reference.
Ah, I misunderstood what you meant.
As far as I know the delta family boards drivers support the synchronization of up to 4 audio boards over PCI: at the moment I'm reverse engineering the hardware trying to understand how this can be accomplished.
I'm aware that some Windows users are using several Delta 1010s without external sync, but I'm not sure how it is done (or how good it sounds). AFAIK it would require a VCXO so that the frequency of the card's clock could be varied by enough to keep it in sync (ie. making the clock oscillator part of a phase locked loop). Looking at the PCI card on the 1010, I can only see standard fixed-frequency crystals. The only PLLs appear to be the internal PLL in the S/PDIF receiver and the 4046 PLL chip for the word clock input signal.
John
John Rigg wrote:
On Tue, Sep 18, 2007 at 10:07:05AM +0200, Ludovico Verducci wrote:
As far as I know the delta family boards drivers support the synchronization of up to 4 audio boards over PCI: at the moment I'm reverse engineering the hardware trying to understand how this can be accomplished.
I'm aware that some Windows users are using several Delta 1010s without external sync, but I'm not sure how it is done (or how good it sounds). AFAIK it would require a VCXO so that the frequency of the card's clock could be varied by enough to keep it in sync (ie. making the clock oscillator part of a phase locked loop). Looking at the PCI card on the 1010, I can only see standard fixed-frequency crystals. The only PLLs appear to be the internal PLL in the S/PDIF receiver and the 4046 PLL chip for the word clock input signal.
In theory, it should be possible to use the PCI clock (between 25 and 33 MHz) as input for one of the PLLs, probably after dividing it down.
Regards, Clemens
Il giorno 18/set/07, alle ore 15:50, Clemens Ladisch ha scritto:
John Rigg wrote:
On Tue, Sep 18, 2007 at 10:07:05AM +0200, Ludovico Verducci wrote:
As far as I know the delta family boards drivers support the synchronization of up to 4 audio boards over PCI: at the moment I'm reverse engineering the hardware trying to understand how this can be accomplished.
I'm aware that some Windows users are using several Delta 1010s without external sync, but I'm not sure how it is done (or how good it sounds). AFAIK it would require a VCXO so that the frequency of the card's clock could be varied by enough to keep it in sync (ie. making the clock oscillator part of a phase locked loop). Looking at the PCI card on the 1010, I can only see standard fixed-frequency crystals. The only PLLs appear to be the internal PLL in the S/PDIF receiver and the 4046 PLL chip for the word clock input signal.
Yes, I agree. If there's a way to achieve this kind of synchronization it isn't simple, at first sight. I'm trying to reconstruct the board's schematics and studying components' data sheets to figure out a way to make it work.
In theory, it should be possible to use the PCI clock (between 25 and 33 MHz) as input for one of the PLLs, probably after dividing it down.
This could be also an option, but I really hope that the feature can be implemented in software because I surely cannot synch over ethernet the PCI clocks! Let's see...
Regards, Ludovico
On Tue, Sep 18, 2007 at 03:50:04PM +0200, Clemens Ladisch wrote:
John Rigg wrote:
On Tue, Sep 18, 2007 at 10:07:05AM +0200, Ludovico Verducci wrote:
As far as I know the delta family boards drivers support the synchronization of up to 4 audio boards over PCI: at the moment I'm reverse engineering the hardware trying to understand how this can be accomplished.
I'm aware that some Windows users are using several Delta 1010s without external sync, but I'm not sure how it is done (or how good it sounds). AFAIK it would require a VCXO so that the frequency of the card's clock could be varied by enough to keep it in sync (ie. making the clock oscillator part of a phase locked loop). Looking at the PCI card on the 1010, I can only see standard fixed-frequency crystals. The only PLLs appear to be the internal PLL in the S/PDIF receiver and the 4046 PLL chip for the word clock input signal.
In theory, it should be possible to use the PCI clock (between 25 and 33 MHz) as input for one of the PLLs, probably after dividing it down.
AFAICT neither of these PLLs can receive an input from the PCI clock. The S/PDIF receiver only receives a signal from the S/PDIF input, and the word clock PLL only receives a signal from the WC input in the breakout box (via a pulse shaping circuit to clean up the waveform).
Apart from that, neither of these PLLs is particularly good at removing jitter (and I'd expect the PCI clock to have a high level of jitter), so quality would be reduced.
John
participants (3)
-
Clemens Ladisch -
John Rigg -
Ludovico Verducci