Re: [alsa-devel] snd-bebob : from kernel 4.13 to 5.3.19 and .20
Hi,
On Wed, Oct 30, 2019 at 10:40:18AM +0100, Jean-Paul Argudo wrote:
I'll install Eoan kernel and test my devices. (but I don't have Saffire and Saffire LE...) I'd like you to wait for my test report.
What I can say is that with kernel 4.13 under Ubunto Disco everything was fine :-(
I install Eoan (linux-image-5.3.0-19-generic:5.3.0-19.20) and test ALSA bebob driver with my test devices: - Yamaha GO46 (DM1000 ASIC) - M-Audio FireWire Solo (DM1000 ASIC) - Behringer FCA610 (DM1500 ASIC) - Focusrite SaffirePro 26 I/O (DM1000E)
However I don't find similar discontinuities. This means that you encounter model-specific issue as regression I didn't realized.
For my information, would you please get output from nodes on procfs? * /proc/asound/cardX/firewire/clock * /proc/asound/cardX/firewire/firmware * /proc/asound/cardX/firewire/formation
Additionally, please install 'gir1.2-hinawa-2.0' package, then clone below remote repository: * https://github.com/takaswie/hinawa-utils
This repository includes two scripts to get information from the device: * hinawa-bebob-parser * hinawa-bebob-connection-cui
When your device is detected as sound card '2' and your device is also detected as '/dev/fw1', execute below:
$ ./hinawa-bebob-connection-cui 2 graph-connections $ ./hinawa-bebob-parser 1 2
At startup it lights green ok, but no sound is playable, then the lights turn orange (like it is when it's not working), I hear a "relay sound" (a electric clic of a relay), then, the Saffire LE disapears from the sound menu in Ubuntu sound menu.
Once your device is detected and ALSA bebob driver bound to it, pulseaudio detects it and start PCM substream to get capabilities of the device.
In your case, the PCM substream is corrupted by the discontinuity. Then pulseaudio give up to use the device. As a result, sound menu drops entry of the device.
I guess that the color of LED corresponds to the packet streaming.
On Wed, Oct 30, 2019 at 11:12:01AM +0100, Jean-Paul Argudo wrote:
But something new and maybe interesting for you :
Oct 30 09:25:25 deiphobe pulseaudio[2589]: E: [alsa-sink-BeBoB] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write. Oct 30 09:25:25 deiphobe pulseaudio[2589]: E: [alsa-sink-BeBoB] alsa- sink.c: Most likely this is a bug in the ALSA driver 'snd_bebob'. Please report this issue to the ALSA developers. Oct 30 09:25:25 deiphobe pulseaudio[2589]: E: [alsa-sink-BeBoB] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Practically these logs can be ignored. (I work to suppress the above lines in development period for Linux kernel v5.5.)
**And in kern.log** : at the beggining in the boot sequence (?), between FS-cache lines and usb ones:
Oct 27 21:54:36 deiphobe kernel: [ 8.742105] FS-Cache: N-key=[8] '020001bdc0a800fe'
Oct 27 21:54:40 deiphobe kernel: [ 12.768168] usb 3-4.1: reset high- speed USB device number 5 using xhci_hcd Oct 27 21:54:45 deiphobe kernel: [ 18.294126] snd-bebob fw1.0: transaction failed: no ack Oct 27 21:54:45 deiphobe kernel: [ 18.294167] snd-bebob fw1.0: fail to get section type for isoc out plug 0: -5 Oct 27 21:54:45 deiphobe kernel: [ 18.294172] snd-bebob fw1.0: fail to run AMDTP slave stream:-5 Oct 27 21:54:45 deiphobe kernel: [ 18.306399] firewire_ohci 0000:05:01.0: DMA context still active (0x00000411) Oct 27 21:54:45 deiphobe kernel: [ 18.318425] firewire_ohci 0000:05:01.0: DMA context still active (0x00000411) Oct 27 21:54:47 deiphobe kernel: [ 20.311440] irq_handler: 20 callbacks suppressed Oct 27 21:54:47 deiphobe kernel: [ 20.311441] firewire_ohci 0000:05:01.0: isochronous cycle inconsistent Oct 27 21:54:48 deiphobe kernel: [ 21.322730] firewire_core 0000:05:01.0: phy config: new root=ffc1, gap_count=5
Oct 27 21:54:50 deiphobe kernel: [ 22.970251] rfkill: input handler disabled Oct 27 20:55:10 deiphobe kernel: [ 42.697284] usb 3-4.1: reset high- speed USB device number 5 using xhci_hcd
IEEE 1394 bus 'bus-reset' state. Just before/after the bus-reset, any functionality easily fails. It's better to plug-in the device enough after bootup.
Regards
Takashi Sakamoto
Hi,
Le mercredi 30 octobre 2019 à 20:50 +0900, Takashi Sakamoto a écrit :
Hi,
On Wed, Oct 30, 2019 at 10:40:18AM +0100, Jean-Paul Argudo wrote:
I'll install Eoan kernel and test my devices. (but I don't have Saffire and Saffire LE...) I'd like you to wait for my test report.
What I can say is that with kernel 4.13 under Ubunto Disco everything was fine :-(
I install Eoan (linux-image-5.3.0-19-generic:5.3.0-19.20) and test ALSA bebob driver with my test devices:
- Yamaha GO46 (DM1000 ASIC)
- M-Audio FireWire Solo (DM1000 ASIC)
- Behringer FCA610 (DM1500 ASIC)
- Focusrite SaffirePro 26 I/O (DM1000E)
However I don't find similar discontinuities. This means that you encounter model-specific issue as regression I didn't realized.
ok.
For my information, would you please get output from nodes on procfs?
$ cat /proc/asound/cards 0 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xf7080000 irq 17 1 [headset ]: USB-Audio - Trust GXT 363 headset C-Media Electronics Incÿ Trust GXT 363 headset at usb-0000:00:14.0-7, full spe 2 [U0x46d0x825 ]: USB-Audio - USB Device 0x46d:0x825 USB Device 0x46d:0x825 at usb-0000:00:14.0-4.1, high speed 3 [SaffireLE ]: BeBoB - SaffireLE Focusrite SaffireLE (id:2, rev:1), GUID 00130e010004394c at fw1.0, S400
- /proc/asound/cardX/firewire/clock
$ cat /proc/asound/card3/firewire/clock Sampling rate: 44100 Clock Source: Internal
- /proc/asound/cardX/firewire/firmware
$ cat /proc/asound/card3/firewire/firmware Manufacturer: bridgeCo Protocol Ver: 1 Build Ver: 0 GUID: 0x00130E010004394C Model ID: 0x02 Model Rev: 1 Firmware Date: 20061207 Firmware Time: 140826 Firmware ID: 0x0 Firmware Ver: 16850194 Base Addr: 0x20080000 Max Size: 1572864 Loader Date: 20051019 Loader Time: 094952
- /proc/asound/cardX/firewire/formation
$ cat /proc/asound/card3/firewire/formation Output Stream from device: Rate PCM MIDI 32000 0 0 44100 6 1 48000 6 1 88200 6 1 96000 6 1 176400 0 0 192000 0 0 Input Stream to device: Rate PCM MIDI 32000 0 0 44100 8 1 48000 8 1 88200 8 1 96000 8 1 176400 0 0 192000 0 0
((I had to replug the interface to grab this information, off course... It lasts a few seconds, sometimes minutes, then: * the interface is no longer online, turning from green to orange or * the interface is still green, but my computer is completely frozen (except the mouse pointer :-P))
Additionally, please install 'gir1.2-hinawa-2.0' package, then clone below remote repository:
You forgot to mention a bit here :-)
For the record and former users of debian/ubuntu:
I had to get and install libhinawa-master.. for that, pip3 with meson, ninja, lib + ubuntu package libgirepository1.0-dev
After the library was installed (with both sudo ninja install and/or ninja install), I couldn't use it:
"ValueError: Namespace Hinawa not available"
**I really discourage anyone to try this hard way** : DO INSTEAD:
I finaly managed to download the "build" version of .debs here: https://salsa.debian.org/debian/libhinawa
Then sudo dpkg -i libhinawa-dev_1.4.0-1_amd64.deb libhinawa1_1.4.0- 1_amd64.deb gir1.2-hinawa-2.0_1.4.0-1_amd64.deb
Then I was finaly unable to use your hinawa-utils scripts !!!
This repository includes two scripts to get information from the device:
- hinawa-bebob-parser
- hinawa-bebob-connection-cui
When your device is detected as sound card '2' and your device is also detected as '/dev/fw1', execute below:
$ ./hinawa-bebob-connection-cui 2 graph-connections
./hinawa-bebob-connection-cui 3 graph-connections > graph_connections.txt
(file attached here, hope it gets thru the ML)
$ ./hinawa-bebob-parser 1 2
./hinawa-bebob-parser 1 2 > parser.txt
(same)
At startup it lights green ok, but no sound is playable, then the lights turn orange (like it is when it's not working), I hear a "relay sound" (a electric clic of a relay), then, the Saffire LE disapears from the sound menu in Ubuntu sound menu.
Once your device is detected and ALSA bebob driver bound to it, pulseaudio detects it and start PCM substream to get capabilities of the device.
In your case, the PCM substream is corrupted by the discontinuity. Then pulseaudio give up to use the device. As a result, sound menu drops entry of the device.
I guess that the color of LED corresponds to the packet streaming.
Thank you very much for the information :)
On Wed, Oct 30, 2019 at 11:12:01AM +0100, Jean-Paul Argudo wrote:
But something new and maybe interesting for you :
Oct 30 09:25:25 deiphobe pulseaudio[2589]: E: [alsa-sink-BeBoB] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write. Oct 30 09:25:25 deiphobe pulseaudio[2589]: E: [alsa-sink-BeBoB] alsa- sink.c: Most likely this is a bug in the ALSA driver 'snd_bebob'. Please report this issue to the ALSA developers. Oct 30 09:25:25 deiphobe pulseaudio[2589]: E: [alsa-sink-BeBoB] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Practically these logs can be ignored. (I work to suppress the above lines in development period for Linux kernel v5.5.)
OK.
**And in kern.log** : at the beggining in the boot sequence (?), between FS-cache lines and usb ones:
Oct 27 21:54:36 deiphobe kernel: [ 8.742105] FS-Cache: N-key=[8] '020001bdc0a800fe'
Oct 27 21:54:40 deiphobe kernel: [ 12.768168] usb 3-4.1: reset high- speed USB device number 5 using xhci_hcd Oct 27 21:54:45 deiphobe kernel: [ 18.294126] snd-bebob fw1.0: transaction failed: no ack Oct 27 21:54:45 deiphobe kernel: [ 18.294167] snd-bebob fw1.0: fail to get section type for isoc out plug 0: -5 Oct 27 21:54:45 deiphobe kernel: [ 18.294172] snd-bebob fw1.0: fail to run AMDTP slave stream:-5 Oct 27 21:54:45 deiphobe kernel: [ 18.306399] firewire_ohci 0000:05:01.0: DMA context still active (0x00000411) Oct 27 21:54:45 deiphobe kernel: [ 18.318425] firewire_ohci 0000:05:01.0: DMA context still active (0x00000411) Oct 27 21:54:47 deiphobe kernel: [ 20.311440] irq_handler: 20 callbacks suppressed Oct 27 21:54:47 deiphobe kernel: [ 20.311441] firewire_ohci 0000:05:01.0: isochronous cycle inconsistent Oct 27 21:54:48 deiphobe kernel: [ 21.322730] firewire_core 0000:05:01.0: phy config: new root=ffc1, gap_count=5
Oct 27 21:54:50 deiphobe kernel: [ 22.970251] rfkill: input handler disabled Oct 27 20:55:10 deiphobe kernel: [ 42.697284] usb 3-4.1: reset high- speed USB device number 5 using xhci_hcd
IEEE 1394 bus 'bus-reset' state. Just before/after the bus-reset, any functionality easily fails. It's better to plug-in the device enough after bootup.
I'll try this if any..
Typically, the unit gets up around the X.org starts...
Thanks again!
Really hope the log info included here helps :)
++
Regards
Takashi Sakamoto
Hi,
I'm sorry to be late for reply but I have a short vacation in this week.
On Wed, Oct 30, 2019 at 03:40:03PM +0100, Jean-Paul Argudo wrote:
- /proc/asound/cardX/firewire/firmware
$ cat /proc/asound/card3/firewire/firmware Manufacturer: bridgeCo Protocol Ver: 1 Build Ver: 0 GUID: 0x00130E010004394C Model ID: 0x02 Model Rev: 1 Firmware Date: 20061207 Firmware Time: 140826 Firmware ID: 0x0 Firmware Ver: 16850194 Base Addr: 0x20080000 Max Size: 1572864 Loader Date: 20051019 Loader Time: 094952
Before vacation I made arrangement to buy Focusrite Saffire LE in used market and today it arrived. As long as I can see, the unit uses the same firmware which your unit uses.
At startup it lights green ok, but no sound is playable, then the lights turn orange (like it is when it's not working), I hear a "relay sound" (a electric clic of a relay), then, the Saffire LE disapears from the sound menu in Ubuntu sound menu.
I can regenerate this phenomena.
I can see this in dmesg:
[ 19.083583] snd-bebob fw1.0: Detect discontinuity of CIP: 10 50 [ 19.746665] snd-bebob fw1.0: Detect discontinuity of CIP: A0 A8 ... [ 284.965508] snd-bebob fw1.0: Detect discontinuity of CIP: D0 10 [ 285.469348] snd-bebob fw1.0: Detect discontinuity of CIP: 68 A8 [ 285.965174] snd-bebob fw1.0: Detect discontinuity of CIP: 20 60 [ 285.981618] firewire_core 0000:05:01.0: phy config: new root=ffc1, gap_count=5 [ 290.103982] firewire_core 0000:05:01.0: phy config: new root=ffc1, gap_count=5
I can see as well.
Then, I realized that these discontinuity occurs in packet streaming of 'second or later'. In short, once disconnection of packet streaming, the unit transfers packets with discontinuity in packet streaming of reconnection. Furthermore, the discontinuity is in the early isoc cycles of packet streaming.
I've already commit to avoid the detection of discontinuity in recent commit for v5.5 kernel (under development): https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound...
In this patch, isoc packets from the device are captured enough after connection to skip early cycles of packet streaming, thus the discontinuity is not detected.
As long as I tested, this version of ALSA BeBoB driver works well with the device. I'd like you to test with backport drivers as well: https://github.com/takaswie/snd-firewire-improve
Regards
Takashi Sakamoto
"Takashi Sakamoto" o-takashi@sakamocchi.jp – November 9, 2019 1:38 PM
Hi,
I'm sorry to be late for reply but I have a short vacation in this week.
On Wed, Oct 30, 2019 at 03:40:03PM +0100, Jean-Paul Argudo wrote:
- /proc/asound/cardX/firewire/firmware
$ cat /proc/asound/card3/firewire/firmware Manufacturer: bridgeCo Protocol Ver: 1 Build Ver: 0 GUID: 0x00130E010004394C Model ID: 0x02 Model Rev: 1 Firmware Date: 20061207 Firmware Time: 140826 Firmware ID: 0x0 Firmware Ver: 16850194 Base Addr: 0x20080000 Max Size: 1572864 Loader Date: 20051019 Loader Time: 094952
Before vacation I made arrangement to buy Focusrite Saffire LE in used market and today it arrived. As long as I can see, the unit uses the same firmware which your unit uses.
At startup it lights green ok, but no sound is playable, then the lights turn orange (like it is when it's not working), I hear a "relay sound" (a electric clic of a relay), then, the Saffire LE disapears from the sound menu in Ubuntu sound menu.
I can regenerate this phenomena.
I can see this in dmesg:
[ 19.083583] snd-bebob fw1.0: Detect discontinuity of CIP: 10 50 [ 19.746665] snd-bebob fw1.0: Detect discontinuity of CIP: A0 A8 ... [ 284.965508] snd-bebob fw1.0: Detect discontinuity of CIP: D0 10 [ 285.469348] snd-bebob fw1.0: Detect discontinuity of CIP: 68 A8 [ 285.965174] snd-bebob fw1.0: Detect discontinuity of CIP: 20 60 [ 285.981618] firewire_core 0000:05:01.0: phy config: new root=ffc1, gap_count=5 [ 290.103982] firewire_core 0000:05:01.0: phy config: new root=ffc1,
gap_count=5
I can see as well.
Then, I realized that these discontinuity occurs in packet streaming of 'second or later'. In short, once disconnection of packet streaming, the unit transfers packets with discontinuity in packet streaming of reconnection. Furthermore, the discontinuity is in the early isoc cycles of packet streaming.
I've already commit to avoid the detection of discontinuity in recent commit for v5.5 kernel (under development): git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound/firewire/bebob
In this patch, isoc packets from the device are captured enough after connection to skip early cycles of packet streaming, thus the discontinuity is not detected.
As long as I tested, this version of ALSA BeBoB driver works well with the device. I'd like you to test with backport drivers as well: github.com/takaswie/snd-firewire-improve
Regards
Takashi Sakamoto _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi Takashi, Hi all,
Le samedi 09 novembre 2019 à 21:36 +0900, Takashi Sakamoto a écrit :
Hi,
I'm sorry to be late for reply but I have a short vacation in this week.
Same here, I was in vacation in Asia until late last week!
On Wed, Oct 30, 2019 at 03:40:03PM +0100, Jean-Paul Argudo wrote:
- /proc/asound/cardX/firewire/firmware
$ cat /proc/asound/card3/firewire/firmware Manufacturer: bridgeCo Protocol Ver: 1 Build Ver: 0 GUID: 0x00130E010004394C Model ID: 0x02 Model Rev: 1 Firmware Date: 20061207 Firmware Time: 140826 Firmware ID: 0x0 Firmware Ver: 16850194 Base Addr: 0x20080000 Max Size: 1572864 Loader Date: 20051019 Loader Time: 094952
Before vacation I made arrangement to buy Focusrite Saffire LE in used market and today it arrived. As long as I can see, the unit uses the same firmware which your unit uses.
Great, thanks for that...
At startup it lights green ok, but no sound is playable, then the lights turn orange (like it is when it's not working), I hear a "relay sound" (a electric clic of a relay), then, the Saffire LE disapears from the sound menu in Ubuntu sound menu.
I can regenerate this phenomena.
Uff! :)
I can see this in dmesg:
[ 19.083583] snd-bebob fw1.0: Detect discontinuity of CIP: 10 50 [ 19.746665] snd-bebob fw1.0: Detect discontinuity of CIP: A0 A8 ... [ 284.965508] snd-bebob fw1.0: Detect discontinuity of CIP: D0 10 [ 285.469348] snd-bebob fw1.0: Detect discontinuity of CIP: 68 A8 [ 285.965174] snd-bebob fw1.0: Detect discontinuity of CIP: 20 60 [ 285.981618] firewire_core 0000:05:01.0: phy config: new root=ffc1, gap_count=5 [ 290.103982] firewire_core 0000:05:01.0: phy config: new root=ffc1, gap_count=5
I can see as well.
Then, I realized that these discontinuity occurs in packet streaming of 'second or later'. In short, once disconnection of packet streaming, the unit transfers packets with discontinuity in packet streaming of reconnection. Furthermore, the discontinuity is in the early isoc cycles of packet streaming.
I've already commit to avoid the detection of discontinuity in recent commit for v5.5 kernel (under development): https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound...
Thanks for the patch, unfortunately I don't have time until this week- end to test the linux kernel version of the patch..
BUT:
In this patch, isoc packets from the device are captured enough after connection to skip early cycles of packet streaming, thus the discontinuity is not detected.
As long as I tested, this version of ALSA BeBoB driver works well with the device. I'd like you to test with backport drivers as well: https://github.com/takaswie/snd-firewire-improve
I tested this DKMS version, it's easier for me and with less impacts.
What I can say is that my unit is running now normaly on my computer, with
$ uname -a Linux deiphobe 5.3.0-20-lowlatency #21-Ubuntu SMP PREEMPT Wed Oct 23 17:03:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
kernel, on Ubuntu 19.10
Running the simple DKMS install version on the README of the snd- firewire-improve, with a recent git clone
Tell me if you need more information so far.
I continue on testing things, but for the moment, 0 problems (I also have a audio unit on USB (GTX headset on USB) for audioconferencing stuff (Zoom) and so far, no problem at all, I can use both.
Same with the NVDIA output over HDMI, on my screen (with a crappy small stereo inside the screen).
Very cool to have the ADAM F7 monitors sound back!!!!!!
**thanks**** !!
Regards
Takashi Sakamoto
participants (3)
-
Jean-Paul Argudo -
Michael Beer -
Takashi Sakamoto