Re: [alsa-devel] ALSA snd-fireworks Echo AudioFire 2
Hi Harry, (C.C.ed to alsa-devel and Clemens)
On Aug 25 2014 09:06, Harry van Haaren wrote:> Hi Takashi,
I can report the AudioFire2 registers correctly, see output: [...] On testing the device with alsa_delay[1], using 256 frames/buffer, 2
buffers.
A sine wave should be audible, however a clicking sound occurs about 3 times per second.
Dmesg prints a list of snd-fireworks logs: [54749.309250] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54749.467216] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54749.627157] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54749.785195] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54749.944205] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54750.102188] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54750.262195] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.420170] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.580185] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.738154] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.898172] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.056187] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.216153] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54751.374195] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.534182] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.692164] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A
The the device works using FFADO, and the mixer settings are all set to pass trough any audio.
Is the above information enough to help debug? Is there anything I can do to assit you in finding this playback bug?
Thanks for your report.
The dmesg means that your AudioFire2 transmits packets with disorder. (I note that Fireworks driver start duplex streams for timestamp synchronization even if you use playback only.)
I know that some Fireworks devices with a certain firmware (not exactly identified) sometimes perform the same behaviour. Could I ask you to confirm to see these logs always when you playback, or sometimes?
# Currently I'm working for moving to my new flat. # So during a few weeks, I may not reply as you expected, sorry.
Regards
Takashi Sakamoto o-takashi@sakamocchi.jp
On Aug 25 2014 09:06, Harry van Haaren wrote:
Hi Takashi,
Thanks for your work on the Echo ALSA support!
I can report the AudioFire2 registers correctly, see output:
/cardX/firewire/clock: Clock Source: 0 Sampling Rate: 44100
/cardX/firewire/meters: Physical Meters: 6 Outputs: Analog [0]: 22784 Analog [1]: 19200 Headphones [0]: 0 Headphones [1]: 0 S/PDIF [0]: 0 S/PDIF [1]: 0 4 Inputs: Analog [0]: 22784 Analog [1]: 19200 S/PDIF [0]: 0 S/PDIF [1]: 0
/cardX/firewire/firmware:
guid_hi: 0x14860E guid_lo: 0xD7FF1CAB type: 0xAF2 version: 0x0 vendor_name: Echo Digital Audio model_name: AudioFire2 dsp_version: 0x0 arm_version: 0x5070300 fpga_version: 0x3000200 flags: 0xA1 max_sample_rate: 0x17700 min_sample_rate: 0x7D00 supported_clock: 0x9 phys out: 0x6 phys in: 0x4 phys in grps: 0x2 phys in grp[0]: type 0x0, count 0x2 phys in grp[1]: type 0x5, count 0x2 phys out grps: 0x3 phys out grps[0]: type 0x0, count 0x2 phys out grps[1]: type 0x5, count 0x2 phys out grps[2]: type 0x1, count 0x2 amdtp rx pcm channels 1x: 0x6 amdtp tx pcm channels 1x: 0x4 amdtp rx pcm channels 2x: 0x6 amdtp tx pcm channels 2x: 0x4 amdtp rx pcm channels 4x: 0x6 amdtp tx pcm channels 4x: 0x4 midi out ports: 0x1 midi in ports: 0x1 mixer playback channels: 0x6 mixer capture channels: 0x4
On testing the device with alsa_delay[1], using 256 frames/buffer, 2 buffers. A sine wave should be audible, however a clicking sound occurs about 3 times per second.
Dmesg prints a list of snd-fireworks logs: [54749.309250] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54749.467216] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54749.627157] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54749.785195] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54749.944205] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54750.102188] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54750.262195] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.420170] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.580185] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.738154] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54750.898172] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.056187] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.216153] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [54751.374195] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.534182] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [54751.692164] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A
The the device works using FFADO, and the mixer settings are all set to pass trough any audio.
Is the above information enough to help debug? Is there anything I can do to assit you in finding this playback bug? Greetings from Ireland, -Harry
[1] http://kokkinizita.linuxaudio.org/linuxaudio/downloads/zita-alsa-pcmi-0.2.0....
On Mon, Aug 25, 2014 at 5:21 AM, Takashi Sakamoto o-takashi@sakamocchi.jp wrote:
(C.C.ed to alsa-devel and Clemens)
Thanks!
I know that some Fireworks devices with a certain firmware (not exactly identified) sometimes perform the same behaviour. Could I ask you to confirm to see these logs always when you playback, or sometimes?
Its consistent: every time it is opened for playback.
To test / debug some more, I've tried starting JACK on the device using ALSA, hw:AudioFire2, duplex, -p256 -n2. QJackCtl reports a stream of xruns: are these the discontinuities similar to the dmesg prints?
I'll try upgrading the firmware on the device (I don't know what version is currently on it). OK: after a flash (using a windows machine), the ASIO driver there now reports the following (latest from Echo) firmware versions:
WDM driver 5.8 ASIO driver 5.8 Console 5.8.1 ARM firmware 5.8 FPGA 3.0.2
Just tried using it, the same type of dmesg discontinuities unfortunately: [ 190.433203] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 190.591959] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 190.749202] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 190.908270] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 191.066267] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 191.225139] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 191.383942] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02
JACK also reports xruns, same as before: flashing the firmware to the latest doesn't seem to have changed anything. The firmware of this device was at 5.7 before the flash, perhaps its "too new" for snd-fireworks in its current state?
# Currently I'm working for moving to my new flat. # So during a few weeks, I may not reply as you expected, sorry.
Good luck with the new place!
I'm new to snd kernel module development, so I'm not sure what the next step is: Guidance and help appreciated, -Harry
Harry van Haaren wrote:
[ 190.433203] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 190.591959] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 190.749202] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 190.908270] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 191.066267] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 191.225139] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 191.383942] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02
JACK also reports xruns, same as before: flashing the firmware to the latest doesn't seem to have changed anything. The firmware of this device was at 5.7 before the flash, perhaps its "too new" for snd-fireworks in its current state?
I suspect these counter values are generated by the hardware; I don't think that the firmware can do anything to affect this. I'll have to check with my own AF2 (which has a much older firmware).
Regards, Clemens
Clemens Ladisch wrote:
Harry van Haaren wrote:
[ 190.433203] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 190.591959] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 190.749202] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 190.908270] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 191.066267] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 191.225139] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 191.383942] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02
JACK also reports xruns, same as before: flashing the firmware to the latest doesn't seem to have changed anything. The firmware of this device was at 5.7 before the flash, perhaps its "too new" for snd-fireworks in its current state?
I suspect these counter values are generated by the hardware; I don't think that the firmware can do anything to affect this.
I do not get any discontinuities with ARM firmware 3.0.2. So much for that theory.
Anyway, if you're up to experimentation, try removing the entire "if (lost)" block from sound/firewire/amdtp.c, and recompiling the drivers. (This will make the driver accept all packets, without fixing the wrong order.)
Regards, Clemens
Hi Harry and Clemens,
On 2014年08月25日 21:09, Harry van Haaren wrote:
On Mon, Aug 25, 2014 at 5:21 AM, Takashi Sakamoto o-takashi@sakamocchi.jp wrote:
(C.C.ed to alsa-devel and Clemens)
Thanks!
I know that some Fireworks devices with a certain firmware (not exactly identified) sometimes perform the same behaviour. Could I ask you to confirm to see these logs always when you playback, or sometimes?
Its consistent: every time it is opened for playback.
Thanks for your confirmation.
In this case, I think there're two causes of discontinuity; one is an actual discontinuity, another is due to wrong parameters in packet header, i.e.:
ALSA: fireworks/firewire-lib: Add a quirk for wrong dbs in tx packets http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/fir...
I suspect the latter reason [1], so I want to see a series of packet header. Would you please apply this patch to your tree and try again to get logs?
https://github.com/takaswie/snd-firewire-improve/commit/0d9763c2d0497a2b2440...
If you have a knowledgement about DKMS, this branch will help your test. https://github.com/takaswie/snd-firewire-improve/tree/af2-debug
When you playback with re-builded snd-firewire-lib (not snd-fireworks, this is an engine for IEC 61883-1/6), you can see much lines in your dmesg output, like:
[ 2308.048941] 042: 00050088 90013b31 [ 2308.048943] 002: 00040090 9001ffff [ 2308.048945] 042: 00050090 9001549b [ 2308.048946] 042: 00050098 90016a05 [ 2308.048948] 002: 000400a0 9001ffff [ 2308.048950] 042: 000500a0 90018370 [ 2308.048952] 042: 000500a8 900198da [ 2308.048954] 002: 000400b0 9001ffff [ 2308.048956] 042: 000500b0 9001b245 [ 2308.048958] 042: 000500b8 9001c7af [ 2308.048960] 042: 000500c0 9001e119 [ 2308.050924] 002: 000400c8 9001ffff (packets transmitted by M-Audio Firewire 410 at 44.1kHz)
If you successfully get these logs, please show it to us. I think logs corresponding to beginning of streaming is helpful.
To test / debug some more, I've tried starting JACK on the device using ALSA, hw:AudioFire2, duplex, -p256 -n2. QJackCtl reports a stream of xruns: are these the discontinuities similar to the dmesg prints?
When detecting packet discontinuity, current ALSA firewire stack changes PCM substream status to XRUN, so jackd show xruns.
I'll try upgrading the firmware on the device (I don't know what version is currently on it). OK: after a flash (using a windows machine), the ASIO driver there now reports the following (latest from Echo) firmware versions:
WDM driver 5.8 ASIO driver 5.8 Console 5.8.1 ARM firmware 5.8 FPGA 3.0.2
You can see the firmware version in 'arm_version' field of proc output:
On Aug 25 2014 09:06, Harry van Haaren wrote:
arm_version: 0x5070300
(This is a firmware for TI IceLynx-Micro. This chipset includes ARM core. In detail, see: http://subversion.ffado.org/wiki/Fireworks)
On Aug 26 2014 05:42, Clemens Ladisch wrote:
I suspect these counter values are generated by the hardware; I don't think that the firmware can do anything to affect this.
I do not get any discontinuities with ARM firmware 3.0.2. So much for that theory.
I think this patch deny this idea.
ALSA: fireworks/firewire-lib: Add a quirk for fixed interval of reported dbc http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/fir...
Fireworks firmware for IceLynx-Micro affects parameters in packet header.
##########
[1] According to IEC 61883-1/6, the interval of 'data block counter' equals to SYT_INTERVAL. At 44.1/48.0 kHz, it's 8 and the number should be multiples of 8. The output from my Firewire 410 follows this specification.
But your log shows wrong number.
On Aug 25 2014 21:09, Harry van Haaren wrote:
[ 190.433203] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 190.591959] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 190.749202] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 190.908270] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 12 [ 191.066267] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 0A [ 191.225139] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02 [ 191.383942] snd-fireworks fw1.0: Detect discontinuity of CIP: 00 02
0x02, 0x0A, 0x12 are not multiples of 8.
In this reason, I suspect that wrong parameters in headers.
##########
Regards
Takashi Sakamoto o-takashi@sakamocchi.jp
participants (3)
-
Clemens Ladisch -
Harry van Haaren -
Takashi Sakamoto