tsched=0 disables timer-based scheduling
audio buffer settings are default-fragments and default-fragment-size-msec
in daemon.conf
archwiki has information showing how to calculate values needed: Setting the default fragment number and buffer size in PulseAudio
formula for fragment size is based on
sample-rate * sample-format * sample-channels:
44100 * 16 * 2 = 1411200 bps
48000 * 24 * 2 = 2304000 bps
96000 * 24 * 2 = 4608000 bps
on an OS with systemd, better to restart Pulseaudio with: systemctl --user restart pulseaudio
usual kill command will restart Pulseaudio but with a different server path and missing modules loaded at boot
can see the changes in pasystray
device would probably work better for 24bit/96kHz in JACK
I would appreciate some testing to see if the cylon issue goes away in JACK, cause I have no clue how to set that up without majorly screwing up my system. The programs that have to work are OBS and KDE’s audio backend.
JACK doesn’t work with OBS unless OBS is built with JACK support, but then you also have to route it specifically in order to get audio from the desktop. It was already a deep rabbit hole to get it working, but it doesn’t work OOTB with neither OBS or KDE’s sound mixer.
Trying to get it working is beyond any reasonable person’s capacity. Pulseaudio is easier to troubleshoot. But I’m not downplaying anyone getting it working on JACK. If you do get it working with JACK, I’d love to see your setup with this thing. (I got it for $100CAD, so it’s great for entry level stuff.)
i have not spent much time using OBS, but i worked out replacing Pulseaudio connection to JACK for a friend to try video streaming his radio shows
i am reinstalling my old desktop in a week or two so will do a JACK/OBS setup and start another linked topic to post data and screenshots
‘cyloning’ is not a term i have heard before. if it is similar to an online bandwidth issue increasing fragment-size setting would be equivalent to increasing bandwidth
pulseaudio default configuration is a safe-minimum. good for working on even old devices. but modern audio hardware can sound much better with a few changes
no need to change defaults /etc/pulse/daemon.conf
make changes in home folder to file ~/.config/pulse/daemon.conf
(if it goes wrong delete custom file and restart to get back on default)
suggest try something like my configuration (except the last setting)
# ~/.config/pulse/daemon.conf
## Custom Configuration file for PulseAudio daemon.
## See 'man pulse-daemon.conf' for more information.
resample-method = speex-float-5
default-sample-format = s24le
default-sample-rate = 48000
default-fragments = 4
default-fragment-size-msec = 16
i have an internal pro-audio card which came out very low on fragment-size calculation
you will probably need a larger value there
calculation is not always reliable so may help to try a few other values
to check new configuration and settings - pulseaudio --dump-conf
The cyloning I almost am certain is because it’s set to 96000hz, but then OBS for a single sample changes Pulseaudio to 48000hz without polling the hardware, resulting in that chip tune “cyloning” where the sample rate is wrong.
I can’t be bothered with JACK because it screwed up my Davinci Resolve installation. Had to re-install to get stuff working again.
Me either but at a guess @FurryJackman do you mean like the noise the Cylons make in Battlestar Galactica? Sorry I no help otherwise but being able to relate the sound to something other people can hear might help if they have come across the noose somewhere else and know what makes it or how it could be made.
there are CMedia CMI codecs on internal cards known to be useless for analog audio capture; but have good audio capture for SPDIF that many cards do not have
if audio capture is generally bad like this it would be at all sample-rates
USB interfaces can cause strange audio effects for listener if using zero-latency monitoring mixed with mic audio playback from system (with delay from longer trip)
if delay time is short microphone will sound will have a ‘comb filter’ like a flanger/phaser guitar pedal
but this would be only the mix heard by user (at all sample-rates)
with only one audio stream in pc, audio would be ok on any recording/VOIP call etc
as problem is only at high sample-rate, still appears to be some bottleneck in audio stream that cannot cope with 2 or 4 * number of bits than lower rates
most likely would be buffer size
possibly choice of resample-method
may help to bypass Pulseaudio and test playback direct to ALSA speaker-test or media player like audacious that can play to ALSA) and bypass
Got a lot on my plate right now so I don’t know if I’ll be able to get to that. Direct ALSA might work if Pulseaudio is completely disabled, but Wine still likes Pulseaudio and most of my games run on Proton…
usually only need to Suspend Pulseaudio or set device profile to ‘Off’
initial premise of review did not mention wine; proton, Davinci Resolve
i was thinking this was a Linux review based on the title
was curious to see if device would work ok in JACK
maybe find out if preamps within device are any good
have seen unverified comments that suggest Zoom devices do not have enough preamp gain
for use with some microphones
Unfortunately, it looks like USB 3.0 controllers (the NEC/Renesas ones) don’t play nice with the U-22 in Linux.
dmesg is flooded with messages like this:
[ 56.027066] xhci_hcd 0000:07:00.0: ERROR: unexpected command completion code 0x11.
[ 56.027071] usb 3-2: Not enough bandwidth for altsetting 1
[ 56.027073] usb 3-2: 1:1: usb_set_interface failed (-22)
And ASmedia keeps throwing error -110 constantly, eventually completely failing just like previous experiences with Fresco Logic controllers on Linux.
VIA controllers without IOMMU on seems to be stable, but it doesn’t work for VFIO, so it’s only if you intend to simply use it without VMs.
This cannot be fixed as XHCI on Linux has been in a severely neglected state for non-chipset USB 3.0 controllers. (Fresco Logic, NEC/Renesas, ASmedia). Using a Hub also doesn’t work if it didn’t work with a direct connection on these controllers.
You must plug the U-22 into a USB 2.0 ONLY port when using it on Linux on a platform that doesn’t have native USB 3.0 over the chipset. The B450 chipset doesn’t suffer this issue with the 3.0 ports going to the CPU or the chipset, but it has the same issues if you use the ASmedia ports. (typically the USB 3.1 Gen 2 and the motherboard USB 3.0 header)
This will also be true of any full bandwidth 480mbps high-speed USB DACs on USB 3.0 controllers that are not the AMD or Intel CPU/Chipset on Linux. Avoid ASmedia, NEC, Fresco Logic for these cases.
The Zoom H5 does not suffer from this problem on XHCI controllers on Linux.
BTW, I figured this out. Both default AND alternate sample rates in daemon.conf had to be set. if you leave alternate commented out, it falls back to 48000 and causes the issues.
Is there a a chart of which audio interfaces have which controllers? Seems like all of the regularly recommended ones are fine and there isn’t much of a pro/con of any of them (Focusrite, Behringer, Steinberg, etc).
Unfortunately not many have torn down their interfaces to find out the chips inside. Teardowns of newer audio interfaces are pretty few and far between.
Obs wont accept 96 khz, the highest is 48khz, Make sense to keep audio a bit smaller. the files go big quicker. And in most cases the sample rate of 48k samples is fast enough. Best practice is to look what sample rates the device can handle in your chain. and then go for the highest sample rate of the weakest point in your line. In this case 48khz.
If your death set on using 96 khz you can always record that in other software. And then video eddit that in. But it will cost you more time. And the sound won’t be any better.
And its not even a linux or jack problem. Even windows screws up if you change from 48kh to 96khz and then to 44khz. and if i close cubase after that nine times out of 10 i have to config all my soundcards in windows back to the khz i have my Presonus soundcard in at the moment.