In D45164#1033838, @christos wrote:Tests with ossinfo(1) run fine.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Today
Today
dev_submerge.ch added inline comments to D45312: sound: Fix minchn, maxchn and fmts in sndstat_get_caps().
Yesterday
Yesterday
dev_submerge.ch added a comment to D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
In my tests this worked as expected with unavailable devices, both in mixer(8) and audio/oss ossinfo.
dev_submerge.ch added a comment to D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
All in all the output shows up correctly now in ossinfo, except for the issues already mentioned here.
Mon, May 20
Mon, May 20
dev_submerge.ch added inline comments to D45256: sound: Handle unavailable devices in various OSS IOCTLs.
dev_submerge.ch added inline comments to D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
In D45256#1032314, @christos wrote:@dev_submerge.ch I am not really sure if we can implement this in SNDCTL_ENGINEINFO as well. In SNDCTL_ENGINEINFO we choose an "engine"/channel on a device that is already opened, so in the case of an unavailable device, we won't be able to open it in the first place.
dev_submerge.ch added inline comments to D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
The patch is fine as is, but it does not fully address the issue described in the commit message, only D45256 does actually resolve it. You could either merge the two commits (and commit messages) when D45256 is ready, or adapt the commit messages to describe what part of the issue is addressed in each.
dev_submerge.ch added a comment to D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
Uhm, sorry again, how do I take back the review accepted and change requested flags?
dev_submerge.ch requested changes to D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
Sorry, this was meant for D45150, "Login to comment" took me to the wrong page.
dev_submerge.ch added inline comments to D45154: mixer.3: Showcase example of how to loop through all mixers.
dev_submerge.ch accepted D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
The patch is fine as is, but it does not fully address the issue described in the commit message, only D45256 does actually resolve it. You could either merge the two commits (and commit messages) when D45256 is ready, or adapt the commit messages to describe what part of the issue is addressed in each.
Sat, May 18
Sat, May 18
The current check is never false and If nvlist_unpack(), we might panic later down the road.
Sun, May 12
Sun, May 12
dev_submerge.ch added inline comments to D45164: sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO.
Sat, May 11
Sat, May 11
In D45150#1030167, @christos wrote:In D45150#1029983, @dev_submerge.ch wrote:We're missing a piece of the puzzle, as mixer_oss_mixerinfo() still skips unavailable devices. Which means SNDCTL_MIXERINFO returns an error instead of a device with enabled == 0, thus breaking the ossinfo utility from audio/oss, and probably other software using the same approach.
That's right. So before I implement this I want to make sure we agree on what each oss_mixerinfo field should contain:
dev loop counter id mixer<loop counter> (unavailable) name Perhaps something like pcm<loop_counter>:mixer (unavailable) modify_counter 0 card_number loop counter port_number 0 enabled 0 caps Not supported. nrext Not supported. priority Not supported. devnode Nothing. legacy_device loop counter I am not really sure whether we want to include the mixer name in id and name or simply leave it blank, or unavailable.
Fri, May 10
Fri, May 10
In D45150#1029901, @christos wrote:@dev_submerge.ch Can you test that this and D45151 fix the problem? I cannot reproduce it right now.
dev_submerge.ch added a comment to D45144: sound: Remove ncards variable from sound_oss_card_info().
In D45144#1029847, @christos wrote:In D45144#1029831, @dev_submerge.ch wrote:This is ok as is, but it has the same problem as SNDCTL_MIXERINFO: We should consider returning "blank" oss_card_info structs for unavailable devices / device indices, instead of an error. Current implementation breaks audio/oss and probably kodi when devices are unavailable, since they stop iterating the SNDCTL_CARDINFO indices if there's an error. There is no enabled in oss_card_info to signal that a device is unavailable, but the info is mostly descriptive. We could return "unavailable" or something like that in the strings, which would hopefully be picked up by the application and shown to the user.
You are talking about the !PCM_REGISTERED(d) case right?
This is ok as is, but it has the same problem as SNDCTL_MIXERINFO: We should consider returning "blank" oss_card_info structs for unavailable devices / device indices, instead of an error. Current implementation breaks audio/oss and probably kodi when devices are unavailable, since they stop iterating the SNDCTL_CARDINFO indices if there's an error. There is no enabled in oss_card_info to signal that a device is unavailable, but the info is mostly descriptive. We could return "unavailable" or something like that in the strings, which would hopefully be picked up by the application and shown to the user.
Thu, May 9
Thu, May 9
In D45135#1029526, @christos wrote:mixer_get_nmixers() returns the oss_sysinfo->nummixers, which, in 277615's case at least, is 5, but we have 8 sound cards, just 3 of them do not have a mixer. So now in mixer(8) we are looping from 0 to 5 and we start opening from /dev/mixer0 to /dev/mixer4, and this is why we're failing to open /dev/mixer0 as his error message reports.
I think a solution can be to get the number of sound cards (i.e oss_sysinfo->numcards) as opposed to the number of mixers, loop through them and if we fail to open a mixer, continue to the next one without printing any error/warning. I can add a mixer_get_ncards() routine to do this.
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:
dev_submerge.ch added a comment to D45112: snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver..
@br does hdsp_running() look correct now? I did some brief tests, seems to work.
dev_submerge.ch updated the diff for D45112: snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver..
Address the issues reported by Li-Wen Hsu and Ruslan Bukin.
Wed, May 8
Wed, May 8
dev_submerge.ch added inline comments to D45112: snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver..
Tue, May 7
Tue, May 7
dev_submerge.ch added a comment to D45112: snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver..
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).
dev_submerge.ch requested review of D45112: snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver..
Mon, May 6
Mon, May 6
dev_submerge.ch added inline comments to D45013: sound: Remove unused dsp_cdevs[] fields and devices.
dev_submerge.ch accepted D45095: sound: Remove unused "num" argument from chn_init() and related callers.
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
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
Wed, May 1
In D45013#1027058, @christos wrote:No objection. Do you think we should also remove the OSSv4 aliases?
In D45013#1026752, @christos wrote:In D45013#1026750, @emaste wrote:I don't think there's a lot of value in keeping the aliases, if we don't also keep the behaviour -- i.e., if some application does expect to open /dev/dspW and send 16-bit samples without doing any other configuration it's not going to work as expected.
True, but if we delete them the program will just exit, which I don't know if it's any better. I am not very keen on keeping those aliases either however, so I am open to suggestions.
In D44993#1026748, @christos wrote:@dev_submerge.ch If there's nothing else that needs fixing I think we can go ahead with it.
Tue, Apr 30
Tue, Apr 30
In D45013#1026747, @christos wrote:In D45013#1026741, @emaste wrote:how does e.g. /dev/dspW map to 16-bit now?
It doesn't since e8c0d15a64fa, and in fact, I just realized that accessing them doesn't work, as is expected. What we can do is:
- Make them /dev/dsp aliases, like the OSS-compat devices.
- Remove them.
I am more inclined to do the former, just in case there's a program that uses /dev/dspW, /dev/audio or /dev/dspcd. @dev_submerge.ch what do you think?
In D45015#1026744, @christos wrote:In D45015#1026743, @dev_submerge.ch wrote:What is this diff based on? I can't apply it on any branch I have.
I forgot to stack the patches, but it is diffed against the previous ones. I thought it wasn't needed, but I can diff against main and reupload if you want.
What is this diff based on? I can't apply it on any branch I have.
Mon, Apr 29
Mon, Apr 29
Sun, Apr 28
Sun, Apr 28
Did some testing, works fine for me.
dev_submerge.ch added a comment to D44923: sound: Fix panic caused by sleeping-channel destruction during asynchronous detach.
In D44923#1025753, @christos wrote:@dev_submerge.ch So, both setting CHN_F_DEAD in the non-sleeping case, and implementing chn_shutdown() and calling it from pcm_unregister() and pcm_killchans() (see below) work fine. Do you think it's better to just with the latter?
dev_submerge.ch added a comment to D44923: sound: Fix panic caused by sleeping-channel destruction during asynchronous detach.
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.
dev_submerge.ch added inline comments to D44923: sound: Fix panic caused by sleeping-channel destruction during asynchronous detach.
Fri, Apr 26
Fri, Apr 26
In D44978#1025409, @br wrote:In D44978#1025398, @dev_submerge.ch wrote:@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.
Could you please check that your HDSPe AIO card is still recognized with this patch? Would be nice to have this fixed in upcoming 14.1-RELEASE, thus the short-term MFC.
Let me check. BTW should this work for HDSPe AIO Pro? I don't have it but I'm curious
@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.
dev_submerge.ch requested review of D44978: snd_hdspe(4): Recognize newer firmware's PCI vendor id..
Wed, Apr 24
Wed, Apr 24
Tue, Apr 23
Tue, Apr 23
Apr 6 2024
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
Apr 1 2024
Mar 31 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
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?
In D44546#1015938, @emaste wrote:So, the patch will break this, but I think OBS has to be patched anyway...
It's not just OBS, it was just the first match that I recognized. GitHub turns up 1.8k instances of "/dev/sndstat": https://github.com/search?q=%2Fdev%2Fsndstat&type=code
Of course some (lots?) of these won't apply (e.g. old unused Linux OSS functionality) but this will definitely take some work and coordination.
Mar 28 2024
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?
In D44411#1015718, @christos wrote:In D44411#1015704, @dev_submerge.ch wrote: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+0xf8I was able to reproduce this a second time, with some "luck" in timing.
Didn't investigate yet, I want to do some more testing first.
Can you share the exact commands you ran to get this?
Mar 27 2024
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 21 2024
In D44411#1012824, @christos wrote:@dev_submerge.ch Also do you think setting the format SND_FORMAT(AFMT_U8, 1, 0) and the rate to DSP_DEFAULT_SPEED in dsp_open() is correct? They get overriden by the VCHAN settings anyway.
Mar 19 2024
Mar 19 2024
In D44411#1012824, @christos wrote:@dev_submerge.ch Does this patch build on your machine?
Mar 16 2024
Mar 16 2024
In D44084#1010276, @br wrote:In D44084#1005680, @dev_submerge.ch wrote: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.
Ruslan, does the calculation of position and length look reasonable to you? We have to store the playback writing position extra because we don't set it in the sndbuf structure.
looks ok to me, I have been testing this for about a week -- no issues
Feb 26 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.
dev_submerge.ch added a comment to D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..
In D44051#1005669, @christos wrote:I mean that it'd be more helpful to have a more descriptive message than " Implement sample rate selection in a more robust way".
dev_submerge.ch updated the summary of D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..
Feb 25 2024
Feb 25 2024
dev_submerge.ch added a comment to D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..
In D44051#1005595, @christos wrote:LGTM. The only thing I'd point out is that it would be better to have a brief description of the code in the commit message.
Feb 24 2024
Feb 24 2024
dev_submerge.ch added a comment to D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..
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).
dev_submerge.ch requested review of D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..
Feb 17 2024
Feb 17 2024
Correct man page regarding number of channels for HDSPe AIO cards.
In D43798#1002381, @br wrote:In D43798#999017, @dev_submerge.ch wrote: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.
I have set hw.hdspe.unified_pcm=1 and tested playback mono (s32le:1.0) and stereo on Line output
help needed with jackit config to test this properly!
Feb 14 2024
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 13 2024
In D43835#1000712, @olce wrote:The PRIV_SCHED_SETPOLICY and PRIV_SCHED_SET privileges are inconsistent with some other places and can be circumvented. Additionally, I don't think they serve any real security purposes (beyond what PRIV_SCHED_RTPRIO and PRIV_SCHED_IDPRIO can provide).
Feb 11 2024
Feb 11 2024
Taken here from PR 276962.
Feb 10 2024
Feb 10 2024
Definitely an improvement, the previous behavior was confusing.
Feb 9 2024
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 :-)