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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
