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