Re: [alsa-devel] ALSA firewire kernel branch: snd_dice enhancements
On 02.11.2011, at 21:19, Clemens Ladisch clemens@ladisch.de wrote:
To get samplerate switching working via ALSA's driver API I have made a few changes, especially within the dice_hw_params callback method. Plus, I enhanced the rate constraints for the pcm settings.
On the DICE, the playback and capture streams must use a common rate, so I thought I'd avoid handling this in the driver and just use whatever was configured.
Isn't common rate for playback & capture stream often required? This could be guaranteed by adapting the pcm rate constraints when acquiring one or the other stream.
Do you have a requirement that the sample rate must be selected automatically, instead of being configured with a control panel or with a CLI tool like amixer?
Yes, this is quite crucial as we are attempting a playback system without any local GUI/control panel/CLI interaction, using jackd as audio backend I/O plugin. E.g. starting jackd with
jackd -d alsa -d hw1:0 -r <rate>
should incorporate switching the samplerate automatically, as this is done with most alsa devices. Given that the ALSA driver API provides for such functionality (snd_xxx_hw_params & snd_xxx_prepare) I thought that such an objective was self-evident. I could think of several other usecases where this would be desired/required. Why _shouldn't_ the application which acquires the DICE device at least be able to dictate the initial samplerate and/or syncsource? What do you (and others) think? Any way we can reach a mutual consent on this?
I hope that some of these enhancements will make it to your alsa-kernel branch, if not even to the 3.x kernel tree (is this being considered for the near future?).
This branch will land in the kernel when it's reasonably complete.
The plan is for this kernel driver to replace FFADO's streaming component.
If this is the case it would appear that automatical samplerate switching, as is provided by FFADO, is a crucial requirement that should also be transferred to this new kernel driver.
I noticed that amdtp_out_stream offers support for "dualwire" streaming at high rates, which is applied for dice's stream. Has this already been considered in FFADO?
Not by anyone who understands the FFADO internals and has the time.
Ok, I'll have a look at it.
2.) support DICE capture streams
I'm working on this right now (modulo the amount of time available).
Excellent, we're happy to serve as guinea pigs, whenever you're ready ;-)
3.) DICE clock source (CLOCK_SOURCE_*) selectable via ALSA driver API; how could this be done?
If not done by a control panel, this could be done with a mixer control. This is not yet implemented because any clock source except ARX* requires synchronization from the capture stream.
I have changed the default clock source to INTERNAL, since I was experiencing "slips" with ARX1; as far as I know ARX1/2 is reasonably applicable only if there is another clock sync master on the Firewire bus.
The timing of the stream from the computer to the DICE is synthesized according to the rules in the AMDTP spec (I hope); this was originally written for devices based on the OXFW970 chip. (It's synchronized to the FireWire bus clock.) It's possible that DICE devices want to use a different value for the transfer delay or some other timing parameter; a stream whose timing is derived from another DICE's capture stream would have whatever timing is required.
ARX1 appears to work fine with my DesktopKonnekt6, but I've never looked at the error counters.
Right, hmm, having scanned the AMDTP (IEC 61883-6) in detail raises some confusion now. Up till now I was under the impression that using AVS-SYT as DICE's clock source is only an option to sync firewire bus slave devices to a clock master device on the same bus. After all, the DesktopKonnekt6 manual mentions that in standalone setup INTERNAL syncsource is selected per default and can not be altered.
Citing from DICE's users guide (chapter 6: AVS (Audio Video System)): "[...] All nodes on a 1394 network must be synchronized to one clock called the cycle timer, which is determined by the master node on the network. One cycle of the master nodes‘ cycle timer defines a 1394 cycle. At the beginning of each 1394 cycle the master node transmits a clock sync signal that allows all nodes on the 1394 network to be synchronized to the cycle timer. This maintains synchronicity among all the 1394 nodes. Each 1394 node receives the clock sync signal and uses it to update or correct its local timer. However, this clock correction can cause the local timer to jump forward or backward as it is updated by the clock sync signal, which can reduce the performance of the system. The format of a quadlet of audio data passing through the AVS is configurable. The AVS can be configured to be transparent for 32-bit audio data. In this case the data will not be touched as it passes through the AVS. The AVS can also be configured to support the IEC61883-6 (AM824) steaming model. This allows the AVS to either source AM824 labels from another location, or build its own AM824 labels for the 24-bit data. The AVS can take the various label fields (block sync, user bits, channel status bits, etc) that make up each AM824 label, from different sources, and then pack them together into an AM824 label. [...]"
Still confused... any enlightenment or recommendation, perhaps from TCAT, on this?
Regards, Rolf
Rolf Anderegg wrote:
On 02.11.2011, at 21:19, Clemens Ladisch clemens@ladisch.de wrote:
On the DICE, the playback and capture streams must use a common rate, so I thought I'd avoid handling this in the driver and just use whatever was configured.
Isn't common rate for playback & capture stream often required?
Yes (but not on consumer chips, where it's normal to have independent clocks for all I/Os).
This could be guaranteed by adapting the pcm rate constraints when acquiring one or the other stream.
Yes, and many ALSA drivers already do this. I just wanted to be lazy and put the sample rate selection into a control panel, where other similar settings already have to be handled.
Putting rate and clock selection in the driver also has the benefit of making it mostly usable even without a control panel.
The timing of the stream from the computer to the DICE is synthesized according to the rules in the AMDTP spec (I hope); this was originally written for devices based on the OXFW970 chip. (It's synchronized to the FireWire bus clock.)
This parenthesis is very misleading; what I should have said is that the driver computes the SYT timestamps so that the stream's sample clock is effectively synchronized to the bus clock. These OXFW970-based devices are playback-only and work the same as DICEs with AVS-SYT clock source, i.e., they should also be able to be synchronized to any other device.
ARX1 appears to work fine with my DesktopKonnekt6, but I've never looked at the error counters.
Right, hmm, having scanned the AMDTP (IEC 61883-6) in detail raises some confusion now. Up till now I was under the impression that using AVS-SYT as DICE's clock source is only an option to sync firewire bus slave devices to a clock master device on the same bus.
And this clock master could be either another device that generates SYT timestamps based on its own internal clock, or a computer that just computes the SYTs. (AFAICT the Windows/OSX DICE drivers don't implement the second case. An 'invented' clock isn't useful except for the playback-only devices mentioned above where there just isn't any other clock.)
Regards, Clemens
participants (2)
-
Clemens Ladisch -
Rolf Anderegg