All audio coming from the MOTU M4 audio interface is distorted. There is a high frequency buzz on top of all sounds, both sounds generated by FreeBSD over USB and external analog inputs. I've tried all a lot of sysctl combinations but no difference at all. As I said this affects all analog inputs with direct monitoring. For example with the computer OFF I can connect an external signal generator to one analog input and hear it. Once I boot FreeBSD and do something audio related like opening a YouTube tab it starts distorting the external signal as well as YouTube. Now if I close the YouTube tab the external signal is clean again and the distortion is gone. My guess is that something with the uaudio initialization messes up the audio interface internals. POTENTIAL FIX: This has nothing to do with PulseAudio as it happens on a base installation with no pkgs. BUT the only fix I've found is to either start or kill the PulseAudio daemon with 'pulseaudio -D' or 'pulseaudio -k'. So something in the PulseAudio init/shutdown code is pokes something which fixes the audio. Note that this has to be repeated every time audio is reinitialized, so if you close YouTube and later open it again you would have to do the PulseAudio trick again. Maybe stepping through the PA init code to find what function call fixes it would help. INFO: root@marcus:~ # freebsd-version 13.1-RELEASE-p5 root@marcus:~ # dmesg | grep -i audio hdaa0: <NVIDIA (0x0099) Audio Function Group> at nid 1 on hdacc0 uaudio0 on uhub1 uaudio0: <MOTU M4, class 239/2, rev 2.00/2.02, addr 4> on usbus3 uaudio0: Play[0]: 192000 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 176400 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 96000 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 88200 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 48000 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play[0]: 44100 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 192000 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 176400 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 96000 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 88200 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 48000 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record[0]: 44100 Hz, 4 ch, 32-bit S-LE PCM format, 2x8ms buffer. uaudio0: MIDI sequencer. pcm4: <USB audio> on uaudio0 uaudio0: No HID volume keys found. root@marcus:~ # sysctl hw.snd hw.snd.maxautovchans: 16 hw.snd.default_unit: 4 hw.snd.version: 2009061500/amd64 hw.snd.default_auto: 1 hw.snd.verbose: 0 hw.snd.vpc_mixer_bypass: 1 hw.snd.feeder_rate_quality: 1 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.feeder_rate_polyphase_max: 183040 hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97 hw.snd.feeder_eq_exact_rate: 0 hw.snd.feeder_eq_presets: PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000 hw.snd.basename_clone: 1 hw.snd.compat_linux_mmap: 0 hw.snd.syncdelay: -1 hw.snd.usefrags: 0 hw.snd.vpc_reset: 0 hw.snd.vpc_0db: 45 hw.snd.vpc_autoreset: 1 hw.snd.timeout: 5 hw.snd.latency_profile: 1 hw.snd.latency: 2 hw.snd.report_soft_matrix: 1 hw.snd.report_soft_formats: 1 root@marcus:~ # sysctl hw.usb.uaudio hw.usb.uaudio.debug: 0 hw.usb.uaudio.buffer_ms: 8 hw.usb.uaudio.default_channels: 0 hw.usb.uaudio.default_bits: 32 hw.usb.uaudio.default_rate: 0 hw.usb.uaudio.handle_hid: 1
Hi, Is this a high-speed USB or full-speed USB device? Try lowering the default sample rate by setting: sysctl hw.usb.uaudio.default_rate=48000 First. Then re-plug your device. Does it change anything? --HPS-- --
According to the manual it's a high-speed device "Available high-speed USB 2.0 (or 3.0) port". It is connected to a blue SS USB port on the motherboard (not a hub). Changing default_rate didn't change anything. I also tried changing that in /etc/sysctl.conf and rebooting. root@marcus:~ # sysctl hw.usb.uaudio hw.usb.uaudio.debug: 0 hw.usb.uaudio.buffer_ms: 8 hw.usb.uaudio.default_channels: 0 hw.usb.uaudio.default_bits: 32 hw.usb.uaudio.default_rate: 48000 hw.usb.uaudio.handle_hid: 1 root@marcus:~ # sysctl dev.pcm.4 dev.pcm.4.feedback_rate: 0 dev.pcm.4.mode: 7 dev.pcm.4.bitperfect: 0 dev.pcm.4.buffersize: 0 dev.pcm.4.rec.vchanformat: s16le:2.0 dev.pcm.4.rec.vchanrate: 48000 dev.pcm.4.rec.vchanmode: fixed dev.pcm.4.rec.vchans: 1 dev.pcm.4.play.vchanformat: s16le:2.0 dev.pcm.4.play.vchanrate: 48000 dev.pcm.4.play.vchanmode: fixed dev.pcm.4.play.vchans: 1 dev.pcm.4.hwvol_mixer: vol dev.pcm.4.hwvol_step: 5 dev.pcm.4.%parent: uaudio0 dev.pcm.4.%pnpinfo: dev.pcm.4.%location: dev.pcm.4.%driver: pcm dev.pcm.4.%desc: USB audio
This value should be in /boot/loader.conf Could you compile a new kernel with "options USB_DEBUG". Then set "sysctl hw.usb.uaudio.debug=15" before plugging the device and capture the resulting dmesg? --HPS
Could you also try to install virtual_oss from ports and configure this using 4 channels and also set the bitperfect sysctl first. Not all applications like 4 channels. Stereo and mono is the most common! Maybe that is the problem. --HPS
Although this device has 4 channels it is only 2 stereo outputs and not surround. This works fine in FreeBSD, I get audio from output 1&2 and not 3&4 which is what I want. Do you still think virtual_oss would help in this case? I can try compiling a new kernel, but it will probably take a while since I have never done that before.
virtual_oss allows you to make ch 3&4 a separate stereo audio device, for example. --HPS
Created attachment 238612 [details] dmesg output GENERIC kernel does seem to have USB_DEBUG defined, so here is the output after unplugging and plugging in the audio interface with debug=15.
The dmesg look good. No signs of problems. Did you try virtual_oss ?
I have tested virtual_oss now but so far I haven't been able to get any sound. Do you have an argument list that should work in my case? I don't quite understand how -C -c should be used. Without virtual_oss I have concluded that hw.usb.uaudio.default_bits=32 is the only bit depth that works, so dev.pcm.4.play.vchanformat should probably be s32 as well. In bitperfect mode that seem to be the only format that I can use, but no applications understand 32 bit 4 channels, but maybe virtual_oss can. I just want stereo sound in channel 1/2 and channel 3/4 to be muted. root@marcus:~ # sysctl dev.pcm.4.bitperfect dev.pcm.4.bitperfect: 1 root@marcus:~ # sysctl dev.pcm.4.play.vchanformat dev.pcm.4.play.vchanformat: s32le:4.0 root@marcus:~ # sysctl dev.pcm.4.play.vchanformat=s16le:2.0 dev.pcm.4.play.vchanformat: s32le:4.0 -> s32le:4.0 root@marcus:~ # sysctl dev.pcm.4.bitperfect=0 dev.pcm.4.bitperfect: 1 -> 0 root@marcus:~ # sysctl dev.pcm.4.play.vchanformat=s16le:2.0 dev.pcm.4.play.vchanformat: s32le:4.0 -> s16le:2.0 root@marcus:~ # sysctl dev.pcm.4.bitperfect=1 dev.pcm.4.bitperfect: 0 -> 1 root@marcus:~ # sysctl dev.pcm.4.play.vchanformat=s16le:4.0 dev.pcm.4.play.vchanformat: s16le:2.0 -> s32le:4.0
Try this: X is the number after "pcm" printed in dmesg. sysctl dev.pcm.X.bitperfect=1 mixer -f /dev/mixerX vol=100 mixer -f /dev/mixerX pcm=100 virtual_oss \ -S \ -i 8 \ -x 85,3,20 \ -C 4 -c 4 -r 48000 -b 32 -s 4ms -f /dev/dspX \ -a 0 -b 32 -c 2 -m 0,0,1,1 -d dsp \ -a 0 -b 32 -c 2 -m 2,2,3,3 -d dsp_secondary \ -t vdsp.ctl # option -C gives the max number of channels in the software mixer # option -c gives the max number of channels for the real device After running the command above, open firefox and play something from youtube. Do you get audio on channel index 0 and 1 (written 1 and 2 on your device)?
virtual_oss reported it couldn't initialize the sample format (-b 32). But changing to -b 16 fixed that but only the first two channels worked (dsp_secondary didn't do anything). I believe this was related to vchanformat which defaults to s16le:2.0. Changing vchanformat when in bitperfect mode however always changes it to s32le:4.0 regardless of what the argument is (see command in previous reply). And when vchanformat is s32le:4.0 nothing works. BUT then I found out that disabling vchans fixes the problem and virtual_oss works as expected with -b 32 and all four channels (both dsp and dsp_secondary works). And the good thing is that now the distortion is gone as well. So I simply do this in /etc/sysctl.conf and initialize virtual_oss like you said. dev.pcm.4.play.vchans=0 dev.pcm.4.rec.vchans=0 dev.pcm.4.bitperfect=1 Not sure what the conclusion is, but something is fishy with OSS and vchans in my case. But then again with virtual_oss you don't need vchans anyway if I understand correctly.
(In reply to mburetorp from comment #12) If you can still reproduce the buzz with pulseaudio (without virtual_oss), it may be worthwhile to get the output of sysctl hw.snd.verbose=2 cat /dev/sndstat both with the buzz present and after the pulseaudio init fix. That should print the vchan conversion graph from pulseaudio output to hardware. Maybe we see a difference there if the vchans are the culprit.
Thanks, maybe this could be something. snddev_flags was changed. snddev flags=0x2e6<AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC> (buzz) snddev flags=0x200002e6<AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC,PRIO_WR> (no buzz)
(In reply to mburetorp from comment #14) Do you happen to have the full output of /dev/sndstat with pulseaudio running? Because it tells a lot about the format conversions vchans do - like mapping 2 channels to 4 and 16 bit samples to 32 bits.
> BUT then I found out that disabling vchans fixes Yes, there might be a bug in the kernel sys/dev/sound/pcm layer. There should be some automagic vchan re-mixing done, when playing back stero on 4-channel devices. It might be that one of the /dev/dspX ioctls fail, and that pulseaudio and other apps simply ignore that ... It might be worth ktracing the applications and grep for the DSP ioctls and see if any have failures. BTW: I always use virtual_oss with USB audio devices having more than 2 channels. --HPS
There is also usbdump, which can dump the contents of the raw audio data send to the isochronous OUT and IN endpoints. If you send some recognizable pattern from your application, then you might get a clue what is going on! --HPS
(In reply to Florian Walpen from comment #15) With YouTube in Firefox playing in the background. First output is when distorting, second output after pulseaudio fix. # cat /dev/sndstat ... pcm4: <USB audio> at ? kld snd_uaudio (1p:1v/1r:1v) default snddev flags=0x2e6<AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC> [pcm4:play:dsp4.p0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002108, 0x00000046 interrupts 1129, underruns 0, feed 2256, ready 0 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2108<TRIGGERED,BUSY,HAS_VCHAN> {userland} -> feeder_mixer(0x00200010) -> feeder_format(0x00200010 -> 0x00201000) -> feeder_matrix(2.0 -> 4.0) -> {hardware} pcm4:play:dsp4.p0[pcm4:virtual:dsp4.vp0]: spd 48000, fmt 0x00200010, flags 0x1000114c, 0x00000021, pid 1766 (firefox) interrupts 0, underruns 0, feed 2256, ready 12436 [b:0/0/0|bs:16384/8192/2] channel flags=0x1000114c<RUNNING,TRIGGERED,NBIO,BUSY,HAS_SIZE,VIRTUAL> {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> {hardware} [pcm4:record:dsp4.r0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002100, 0x00000047 interrupts 0, overruns 0, feed 0, hfree 12288, sfree 4096 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2100<BUSY,HAS_VCHAN> {hardware} -> feeder_root(0x00401000) -> feeder_format(0x00401000 -> 0x00400010) -> feeder_matrix(4.0 -> 2.0) -> feeder_mixer(0x00200010) -> {userland} pcm4:record:dsp4.r0[pcm4:virtual:dsp4.vr0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000 interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0] channel flags=0x10000000<VIRTUAL> {hardware} -> feeder_root(0x00000000) -> {userland} No devices installed from userspace. # pulseaudio -D # pulseaudio -k # cat /dev/sndstat ... pcm4: <USB audio> at ? kld snd_uaudio (1p:2v/1r:1v) default snddev flags=0x200002e6<AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC,PRIO_WR> [pcm4:play:dsp4.p0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002108, 0x00000046 interrupts 3832, underruns 0, feed 7662, ready 0 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2108<TRIGGERED,BUSY,HAS_VCHAN> {userland} -> feeder_mixer(0x00200010) -> feeder_format(0x00200010 -> 0x00201000) -> feeder_matrix(2.0 -> 4.0) -> {hardware} pcm4:play:dsp4.p0[pcm4:virtual:dsp4.vp0]: spd 48000, fmt 0x00200010, flags 0x1000114c, 0x00000021, pid 1766 (firefox) interrupts 0, underruns 0, feed 7662, ready 14208 [b:0/0/0|bs:16384/8192/2] channel flags=0x1000114c<RUNNING,TRIGGERED,NBIO,BUSY,HAS_SIZE,VIRTUAL> {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> {hardware} pcm4:play:dsp4.p0[pcm4:virtual:dsp4.vp1]: spd 44100/48000, fmt 0x00200010, flags 0x10000000, 0x00000029 interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:8192/1024/8] channel flags=0x10000000<VIRTUAL> {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> feeder_rate(0x00200010 q:1 44100 -> 48000) -> {hardware} [pcm4:record:dsp4.r0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002100, 0x00000047 interrupts 609, overruns 0, feed 3641, hfree 12288, sfree 4096 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2100<BUSY,HAS_VCHAN> {hardware} -> feeder_root(0x00401000) -> feeder_format(0x00401000 -> 0x00400010) -> feeder_matrix(4.0 -> 2.0) -> feeder_mixer(0x00200010) -> {userland} pcm4:record:dsp4.r0[pcm4:virtual:dsp4.vr0]: spd 44100/48000, fmt 0x00200010, flags 0x10000000, 0x00000029 interrupts 0, overruns 0, feed 0, hfree 0, sfree 32768 [b:0/0/0|bs:32768/256/128] channel flags=0x10000000<VIRTUAL> {hardware} -> feeder_root(0x00200010) -> feeder_rate(0x00200010 q:1 48000 -> 44100) -> feeder_volume(0x00200010) -> {userland} No devices installed from userspace.
(In reply to mburetorp from comment #18) Ok, so firefox doesn't play through pulseaudio, and opens a vchan for playback. The big difference in the "fixed" case is that pulseaudio seems to create additional vchans for playback _and_ recording. Curiously both at 44.1kHz instead of 48kHz. Maybe the vchan processing has a problem which gets worked around by the additional processing nodes in the graph. Or maybe the hardware likes to run in duplex and any open recording channel fixes that. To check this, you could try to run virtual_oss in playback only mode (-P instead of -f I think) and see if the buzz is there again.
(In reply to Florian Walpen from comment #19) I think you might be right about recording channels. Pressing record in Audacity also fixes the distorted sound similar to Pulseaudio. Here is sndstat again before and after pressing record in Audacity. before (distorted): pcm4: <USB audio> at ? kld snd_uaudio (1p:2v/1r:1v) default snddev flags=0x2e6<AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC> [pcm4:play:dsp4.p0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002108, 0x00000046 interrupts 377, underruns 0, feed 752, ready 0 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2108<TRIGGERED,BUSY,HAS_VCHAN> {userland} -> feeder_mixer(0x00200010) -> feeder_format(0x00200010 -> 0x00201000) -> feeder_matrix(2.0 -> 4.0) -> {hardware} pcm4:play:dsp4.p0[pcm4:virtual:dsp4.vp0]: spd 48000, fmt 0x00200010, flags 0x1000114c, 0x00000021, pid 1784 (firefox) interrupts 0, underruns 0, feed 752, ready 12368 [b:0/0/0|bs:16384/8192/2] channel flags=0x1000114c<RUNNING,TRIGGERED,NBIO,BUSY,HAS_SIZE,VIRTUAL> {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> {hardware} pcm4:play:dsp4.p0[pcm4:virtual:dsp4.vp1]: spd 384000/48000, fmt 0x00100010/0x00200010, flags 0x10000000, 0x00000069 interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:32768/4096/8] channel flags=0x10000000<VIRTUAL> {userland} -> feeder_root(0x00100010) -> feeder_rate(0x00100010 q:1 384000 -> 48000) -> feeder_matrix(1.0 -> 2.0) -> feeder_volume(0x00200010) -> {hardware} [pcm4:record:dsp4.r0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002100, 0x00000047 interrupts 553, overruns 0, feed 3306, hfree 12288, sfree 4096 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2100<BUSY,HAS_VCHAN> {hardware} -> feeder_root(0x00401000) -> feeder_format(0x00401000 -> 0x00400010) -> feeder_matrix(4.0 -> 2.0) -> feeder_mixer(0x00200010) -> {userland} pcm4:record:dsp4.r0[pcm4:virtual:dsp4.vr0]: spd 44100/48000, fmt 0x00200010, flags 0x10000000, 0x00000029 interrupts 0, overruns 0, feed 0, hfree 0, sfree 32768 [b:0/0/0|bs:32768/256/128] channel flags=0x10000000<VIRTUAL> {hardware} -> feeder_root(0x00200010) -> feeder_rate(0x00200010 q:1 48000 -> 44100) -> feeder_volume(0x00200010) -> {userland} after (clean): pcm4: <USB audio> at ? kld snd_uaudio (1p:2v/1r:1v) default snddev flags=0x2e6<AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC> [pcm4:play:dsp4.p0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002108, 0x00000046 interrupts 1299, underruns 0, feed 2596, ready 0 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2108<TRIGGERED,BUSY,HAS_VCHAN> {userland} -> feeder_mixer(0x00200010) -> feeder_format(0x00200010 -> 0x00201000) -> feeder_matrix(2.0 -> 4.0) -> {hardware} pcm4:play:dsp4.p0[pcm4:virtual:dsp4.vp0]: spd 48000, fmt 0x00200010, flags 0x1000114c, 0x00000021, pid 1784 (firefox) interrupts 0, underruns 0, feed 2596, ready 13472 [b:0/0/0|bs:16384/8192/2] channel flags=0x1000114c<RUNNING,TRIGGERED,NBIO,BUSY,HAS_SIZE,VIRTUAL> {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> {hardware} pcm4:play:dsp4.p0[pcm4:virtual:dsp4.vp1]: spd 384000/48000, fmt 0x00100010/0x00200010, flags 0x10000000, 0x00000069 interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:32768/4096/8] channel flags=0x10000000<VIRTUAL> {userland} -> feeder_root(0x00100010) -> feeder_rate(0x00100010 q:1 384000 -> 48000) -> feeder_matrix(1.0 -> 2.0) -> feeder_volume(0x00200010) -> {hardware} [pcm4:record:dsp4.r0]: spd 48000, fmt 0x00200010/0x00401000, flags 0x00002108, 0x00000047 interrupts 556, overruns 0, feed 3324, hfree 12288, sfree 4095 [b:12288/6144/2|bs:4096/2048/2] channel flags=0x2108<TRIGGERED,BUSY,HAS_VCHAN> {hardware} -> feeder_root(0x00401000) -> feeder_format(0x00401000 -> 0x00400010) -> feeder_matrix(4.0 -> 2.0) -> feeder_mixer(0x00200010) -> {userland} pcm4:record:dsp4.r0[pcm4:virtual:dsp4.vr0]: spd 44100/48000, fmt 0x00200010, flags 0x1000114c, 0x00000029, pid 1800 (audacity) interrupts 0, overruns 0, feed 1720, hfree 0, sfree 26428 [b:0/0/0|bs:32768/8192/4] channel flags=0x1000114c<RUNNING,TRIGGERED,NBIO,BUSY,HAS_SIZE,VIRTUAL> {hardware} -> feeder_root(0x00200010) -> feeder_rate(0x00200010 q:1 48000 -> 44100) -> feeder_volume(0x00200010) -> {userland} I haven't tested virtual_oss -P yet but I suspect it will be the same.
(In reply to mburetorp from comment #20) Good to know - that means more options for a workaround. You can probably use any sound daemon, as long as it continuously opens a recording channel: sndiod, pulseaudio, don't know the current state of pipewire. virtual_oss has the additional benefit that it lets you use the secondary stereo outputs. As for a potential fix on the Hardware / USB side, HPS is the expert. The only idea I have is this: If the device stores permanent settings on the device (some MOTUs do), you could experiment with different settings in the proprietary driver on Windows / Mac. Clock settings would be a candidate.
Personally I'm happy with virtual_oss. But I'm not sure how this should be handled by the kernel/driver in the future so that it doesn't confuse more users, or maybe it is fine. Windows MOTU driver control panel offers only sample rate and latency settings.