Closed jpargudo closed 3 years ago
Hi,
Thanks for your report. I did reply in the list: https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/157741.html
Hi !
Thanks a lot!
Let's close this issue here then?
Hi @jpargudo ,
I'd like you to test the latest driver by backporting it into your system, and report your result. https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158294.html
I maintain this repository for this purpose ;)
Thanks
Hi there, i'd like to confirm that once i
I get:
kernel: snd-bebob fw1.0: Detect discontinuity of CIP: 10 E8
...
kernel: Call Trace
...
kernel: Code: Bad RIP value
And the entire saffire LE becomes non responsive
On a reboot, I can use
But there are frequent dropouts
I've used the current master HEAD, and it seems to be working. Oh spoke too soon had an Alsa poll time out and hydrogen that was playing stopped. Now i'm getting one snd-bebob fw1.0: Detect discontinuity CIP: 08 48
Tried other settings frames/period + periods/buffer and it seems to work ok. The performance isn't particularly stellar, and cannot reach <10msec. There's still some xruns, once every 10 - 20 minutes for settings of under 20msec
Might not be related, but everytime qjackctl freezes, i'll have to delete the /dev/shm of jack shared memory files. Might be incidental though. Disregard if it has no impact.
From reading all the issues, it really does seem like the discontinuity in packet streaming eventually leads to a large enough discrepancy that jack using alsa firewire stops working.
https://lore.kernel.org/alsa-devel/ad6f8c036538aa755017efe976ac223bb7c90be3.camel@argudo.org/t/
I'm not sure how he does it, but it's definitely not 10msec latency that works
Hi there,
Le jeudi 05 mars 2020 à 18:51 -0800, muziker a écrit :
From reading all the issues, it really does seem like the discontinuity in packet streaming eventually leads to a large enough discrepancy that jack using alsa firewire stops working.
https://lore.kernel.org/alsa-devel/ad6f8c036538aa755017efe976ac223bb7c90be3.camel@argudo.org/t/
I'm not sure how he does it, but it's definitely not 10msec latency that works
FYI, since that problem I got rid of firewire and the Saffire LE, waiting for better days :-( ...
I can put it back in the box and continue debugging for you if you want. Just tell me how I could help there :/
I think also of putting this in a comparable box I have here, and give you ssh access if you want?...
Just tell me !
Cheers,
-- Jean-Paul
Well, i was hoping you'd have the settings that would solve all the issues. After a lengthy trial by error, i've managed to come to this setting, that so far seems to work, though it still gives a xrun every few minutes or so, they are usually inaudible. Be advised that my machine is one of those macbooks with all the connectors on one side, which means that they might be somehow sharing either a powerline, or some bus controller, which can affect performance.
At first i thought it was a problem with the irqs, but i found using this repo, with alsa, 48k, frames/period 256, periods/buffer 6, non realtime, no verbose messages, no memory lock , and no midi driver, to give a latency of 32 msec. The general issue is probably the cip discontinuity and timing information. I also found some annoying interactions between jackd and the qjackctl settings, in that, to fully ensure the correct values are used, all jack processes must be killed. Also i've disabled pulseaudio permanently on boot, but will have it running later. Though to be fully thorough, the machine needs to be rebooted every change in setting, just to be certain. I didn't do that all the time, relying on pkill to get rid of jack, and ffado-test BusReset to reset the controller.
I really don't know how windows and mac gets this interface running at low latencies.
I attempt to implement media clock recovery to suppress the issue. If still interested, please test current HEAD of topic/media-clock-recovery
remote branch (3a2c5fd52657).
I note that patchset for the issue is posted to upstream:
Thank you @takaswie
I'll try asap.. And give feedback.
@jpargudo
I'll try asap.. And give feedback.
If you try, it's convenient to usetopic/media-clock-recovery
in this repository.
Thanks
The patchset is merged to upstream. The patches are also available in master branch of the repository.
Let me close the issue since no reactions during a recent 10 days.
Hi there,
First, I'm really not sure this is the right place to write an Issue, but I didnt find better on the net, still waiting alsa-devel ML approval... :/
I upgraded my Ubuntu Disco (kernel 4.13) to Ubuntu Eoan (kernel 5.3.19) and I can report my SaffireLE / Firewire doesnt work anymore.
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 the relay sound, then, the Saffire LE disapears from the sound menu.
I can see this in dmesg:
I tried update the kernel with eoan-proposed I know run 5.3.20 and I have the same problem (the trace above is made with 5.3.20.
So please, first: tell me where to report this properly to the proper team... ?
And second, If you have any tools or tips to report better, with a trace on or something?
Thanks a lot !!!!!