[alsa-devel] ALSA firewire kernel branch: snd_dice enhancements
rolf.anderegg at weiss.ch
Fri Nov 4 01:40:10 CET 2011
On 02.11.2011, at 21:19, Clemens Ladisch <clemens at 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
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?
More information about the Alsa-devel