Henrik Enquist
Henrik Enquist
Thanks for the logs. This looks very similar to https://github.com/HEnquist/camilladsp/issues/310 Version 2.0 has some changes to the alsa device buffer and period parameters, to make it work with more devices....
Can you try without dsnoop?
I have tried reproducing the problem on my test system (up-to-date Manjaro on an i3-8400) but here things are running fine. When using the dsnoop plugin, the possible values get...
You could also try defining a custom dsnoop: https://alsa.opensrc.org/Dsnoop#Choosing_recording_rates That way you can set the period smaller than the default 1024. Try 512 or 256.
Thanks for testing! I think the problem may be that the buffer size gets too small compared to the period size. I made an attempt at a more general fix....
Ok so it looks as if things run better with the larger buffer sizes of v1.0. Just increasing the size should not cause any trouble, I'll update that PR. >...
It would be helpful if you can figure out under what conditions you get these very large and strange period sizes. Such a large period will likely lead to all...
512 should be an ok period. Are things working ok now? 5513 is probably the rounded result of 44100/8 = 5512.5.
Some of these buffer underruns are likely caused by using dsnoop, because it prevents the rate adjust from working. When capturing directly from the loopback with "hw:Loopback,0", then CamillaDSP is...
V1.0 just sets the buffer size to 2*chunksize, and period to chunksize/4. This leads to trouble with some quite common devices that don't accept arbitrary values, or have some special...