User Details
- User Since
- Nov 25 2021, 6:20 PM (128 w, 7 h)
Yesterday
Maybe unrelated to this particular piece of code, but I did some tests with two USB sound cards. When I remove the first one (pcm0), the mixer application reveals some flaws:
@br does hdsp_running() look correct now? I did some brief tests, seems to work.
Address the issues reported by Li-Wen Hsu and Ruslan Bukin.
Wed, May 8
Tue, May 7
For those not familiar with snd_hdspe(4), it may be best to compare this with the hdspe.h, hdspe.c and hdspe-pcm.c files in the same directory (sys/dev/sound/pci).
Mon, May 6
Looks good to me, but I cannot compile and test it. Patch doesn't apply here locally because I'm missing previous commits. Time to get that stuff merged ;-)
Ok for me except for the style, see inline comment. Having separate pcm devices for AC3, SPDIF etc may not be appropriate, but we should probably find a way to integrate these settings into the mixer or a future user space audioctl tool.
Sat, May 4
Some of the types (SND_DEV_AUDIO, SND_DEV_DSP16, SND_DEV_DSPHW_CD) in sound.h are unused now, I think. Should we get rid of them or mark them deprecated?
Wed, May 1
Tue, Apr 30
What is this diff based on? I can't apply it on any branch I have.
Mon, Apr 29
Sun, Apr 28
Did some testing, works fine for me.
Actually, my guess is that it would have had some merit to set CHN_F_DEAD unconditionally, early on in pcm_unregister(), beneath waking up sleeping threads. That would mean some code duplication, yes, but less interference from userspace and sleep waiting afterwards. But I don't have a case to back that up.
Fri, Apr 26
@br: I was surprised that after a firmware update of my HDSPe RayDAT card it wasn't recognized anymore on FreeBSD. Turns out RME changed the PCI vendor id to their own instead of the Xilinx one.
Wed, Apr 24
Tue, Apr 23
Apr 6 2024
Hacked it into the sosso test executable to exercise this ioctl, I'm still not convinced of its utility. This lets every application of all users set the device description globally. I think it's useful on a system level (mixer or similar tool), but I'd be wary to use it in an application. For the purposes mentioned in OSSv4, something like virtual_oss can set the description of the pcm devices it creates in a different way.
Apr 1 2024
Mar 31 2024
Do you have a particular interest in this ioctl? I didn't find any software using it on github, just example code from the 4Front OSS docs. Maybe it's a good opportunity to add an OSS API test executable now? Otherwise I have to hack it into sosso or something to run it.
Did another test drive with all patches together, works fine now. Sorry for the long "test cycle", I really have to get a USB expansion card for bhyve passthrough, so I don't have to reboot into CURRENT all the time.
Mar 29 2024
"Good news", I can reproduce the lock order reversal on the main branch, without this patch - it's not related to the changes here. How should we proceed with that?
Mar 28 2024
This is definitely more readable, but my main concern would be that this form of output is quite lengthy and not very grep-friendly. Imagine 8 pcm devices with 4 channels each (when idle). Ideally, we could easily grep for the whole output of a single device, or check which output is used by an application (cat /dev/sndstat | grep mpv). Would be handy for both personal use and bug reports from users. Or maybe we can integrate these selective queries into a user space tool?
Mar 27 2024
The mmap'ed tests worked fine in general, but I hit the following while starting two instances simultaneously:
lock order reversal: 1st 0xfffff8012e17e0a0 pcm7:virtual:dsp7.vr0 (pcm virtual record channel, sleep mutex) @ /usr/src/sys/dev/sound/pcm/dsp.c:2617 2nd 0xfffff8012e17e120 pcm7 (sound cdev, sleep mutex) @ /usr/src/sys/dev/sound/pcm/channel.c:2214 lock order sound cdev -> pcm virtual record channel established at: #0 0xffffffff80bc7b7a at witness_checkorder+0x2fa #1 0xffffffff80b2d200 at __mtx_lock_flags+0x90 #2 0xffffffff808e6b7d at sound_oss_sysinfo+0x1ed #3 0xffffffff808cf810 at dsp_ioctl+0x960 #4 0xffffffff809db8f2 at devfs_ioctl+0xd2 #5 0xffffffff80c63092 at vn_ioctl+0xc2 #6 0xffffffff809dbfce at devfs_ioctl_f+0x1e #7 0xffffffff80bce186 at kern_ioctl+0x286 #8 0xffffffff80bcde93 at sys_ioctl+0x143 #9 0xffffffff8105b473 at amd64_syscall+0x153 #10 0xffffffff8102d10b at fast_syscall_common+0xf8 lock order pcm virtual record channel -> sound cdev attempted at: #0 0xffffffff80bc83e3 at witness_checkorder+0xb63 #1 0xffffffff80b2d200 at __mtx_lock_flags+0x90 #2 0xffffffff808c949a at chn_trigger+0x26a #3 0xffffffff808e9c6c at vchan_trigger+0x12c #4 0xffffffff808c9321 at chn_trigger+0xf1 #5 0xffffffff808d5acb at dsp_oss_syncstart+0x1bb #6 0xffffffff808d0b40 at dsp_ioctl+0x1c90 #7 0xffffffff809db8f2 at devfs_ioctl+0xd2 #8 0xffffffff80c63092 at vn_ioctl+0xc2 #9 0xffffffff809dbfce at devfs_ioctl_f+0x1e #10 0xffffffff80bce186 at kern_ioctl+0x286 #11 0xffffffff80bcde93 at sys_ioctl+0x143 #12 0xffffffff8105b473 at amd64_syscall+0x153 #13 0xffffffff8102d10b at fast_syscall_common+0xf8
I was able to reproduce this a second time, with some "luck" in timing.
My first round of tests was all good, no regressions so far. I still have to test mmap'ed operation, probably tomorrow.
Mar 21 2024
Mar 19 2024
Mar 16 2024
Feb 26 2024
I'm still testing this, but I haven't found any problems in the last few days. It's hard to tell whether this approach is robust against missed interrupts, because I never encountered any.
Feb 25 2024
Feb 24 2024
This passed some manual tests, setting hw.usb.uaudio.default_rate to different values, re-plug the uaudio device and try various sample rates (vchans disabled).
Feb 17 2024
Correct man page regarding number of channels for HDSPe AIO cards.
Feb 14 2024
Thanks for the article, Olivier - now that I know the extent of your project, I suspect it won't be MFC'd?
If that's the case it may be worth to get this minimal fix in right now, and MFC it to STABLE. The earlier this issue is fixed in all supported releases, the less workarounds in ports.
Feb 13 2024
Feb 11 2024
Taken here from PR 276962.
Feb 10 2024
Definitely an improvement, the previous behavior was confusing.
Feb 9 2024
One last thing, sorry for the mess of inline comments.
Just some random testing, with no pcm devices I get:
# mixer -a mixer: mixer_get_nmixers(): No error: 0 # mixer mixer: mixer_open((null)): No error: 0
This case could be handled with a less cryptic message.
This was tested with a HDSPe RayDAT. @br, could you at least test the analog outputs of the AIO? You probably need audio/jack or audio/virtual_oss to handle that many channels. Just ask me if you need help with the setup.
Ok, hopefully last round of comments from my side :-)
Feb 7 2024
Feb 6 2024
Integrated into D43679. The parameter iteration shouldn't produce duplicate entries anymore.
Moved the special treatment of USB 1.1 devices up to where the USB bus speed is
queried. This should clarify the intent to only detect more than 4 channels if
the default_channels is set to a higher value.
Sorry this took some time, but here is a list of info I'd want to have in the man page if I was an end user.
Be specific about when these settings are helpful. We don't want users to set them unnecessarily, due to possible side effects on other uaudio devices.
The only case here is a duplicate sample rate, right? I'm uneasy to do this in the descriptor loop (why?).
Not opposed to this, just note that it may be of limited value. The sample rate can effectively change at runtime, see uaudio_chan_set_param_speed().
Feb 4 2024
Jan 31 2024
Have a look at D43679 - that should make documentation of default_bits and default_channels easier.
Not very elegant, but the whole iteration method here is somewhat crude. The default_rate sysctl already acts like a default, and does not prevent other sample rates from the list. Leave it unchanged.
As communicated in private, the latest update to this change fixes all kernel panics and witness complaints.
Jan 30 2024
Unfortunately I still get the kernel panic when I pull the USB plug, see inline comments.
The case without pulling the plug first: When I stop Jack, there's no kernel panic now, but I get the following messages:
Jan 30 13:59:09 current kernel: exclusive sleep mutex clone lock (clone manager) r = 0 (0xfffff8011ac4d2e0) locked @ /usr/src/sys/dev/sound/clone.c:390 Jan 30 13:59:09 current kernel: stack backtrace: Jan 30 13:59:09 current kernel: #0 0xffffffff80bc7c15 at witness_debugger+0x65 Jan 30 13:59:09 current kernel: #1 0xffffffff80bc8d79 at witness_warn+0x3e9 Jan 30 13:59:09 current kernel: #2 0xffffffff80adf0fe at destroy_dev+0x1e Jan 30 13:59:09 current kernel: #3 0xffffffff80885823 at snd_clone_gc+0x223 Jan 30 13:59:09 current kernel: #4 0xffffffff80885b82 at snd_clone_unref+0x52 Jan 30 13:59:09 current kernel: #5 0xffffffff808cf44b at dsp_close+0x73b Jan 30 13:59:09 current kernel: #6 0xffffffff809db9bf at devfs_close+0x48f Jan 30 13:59:09 current kernel: #7 0xffffffff8112e002 at VOP_CLOSE_APV+0x32 Jan 30 13:59:09 current kernel: #8 0xffffffff80c640a0 at vn_close1+0x100 Jan 30 13:59:09 current kernel: #9 0xffffffff80c626af at vn_closefile+0x3f Jan 30 13:59:09 current kernel: #10 0xffffffff809dc37b at devfs_close_f+0x2b Jan 30 13:59:09 current kernel: #11 0xffffffff80aece5b at _fdrop+0x1b Jan 30 13:59:09 current kernel: #12 0xffffffff80af06c3 at closef+0x1e3 Jan 30 13:59:09 current kernel: #13 0xffffffff80af45e6 at closefp_impl+0x76 Jan 30 13:59:09 current kernel: #14 0xffffffff81058463 at amd64_syscall+0x153 Jan 30 13:59:09 current kernel: #15 0xffffffff8102ab1b at fast_syscall_common+0xf8
Thanks for picking this up, @christos.
Jan 29 2024
Jan 28 2024
FYI, if I disable vchans on the device, the mutex clone kernel panic also occurs when I just stop Jack as usual. Without forcing a device detach by pulling the USB plug. It seems like the mutex owner assertions in snd_clone_wakeup() are violated even without running the pcm_unregister() code first. Hope this helps.
Jan 27 2024
Could you commit it if there are no other issues? Thank you!