Page MenuHomeFreeBSD

dev_submerge.ch (Florian Walpen)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 25 2021, 6:20 PM (125 w, 4 d)

Recent Activity

Sat, Apr 6

dev_submerge.ch added a comment to D44570: sound: Implement SNDCTL_SETNAME.

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.

Sat, Apr 6, 12:12 PM

Mon, Apr 1

dev_submerge.ch accepted D44571: sound: Move sndstat_prepare_pcm() to pcm/sndstat.c and remove sndstat_entry->handler.
Mon, Apr 1, 2:20 PM

Sun, Mar 31

dev_submerge.ch added a comment to D44570: sound: Implement SNDCTL_SETNAME.

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.

Sun, Mar 31, 2:44 PM
dev_submerge.ch accepted D43545: sound: Implement asynchronous device detach.

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.

Sun, Mar 31, 1:57 PM

Fri, Mar 29

dev_submerge.ch accepted D44411: sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9).

"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?

Fri, Mar 29, 4:51 PM
dev_submerge.ch added a comment to D44546: sound: Make verbose sndstat output more readable.

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.

Fri, Mar 29, 2:42 PM

Thu, Mar 28

dev_submerge.ch added a comment to D44546: sound: Make verbose sndstat output more readable.

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?

Thu, Mar 28, 2:16 PM
dev_submerge.ch added a comment to D44411: sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9).

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.

Didn't investigate yet, I want to do some more testing first.

Can you share the exact commands you ran to get this?

Thu, Mar 28, 1:12 PM

Wed, Mar 27

dev_submerge.ch added a comment to D44411: sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9).

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.

Wed, Mar 27, 11:36 PM
dev_submerge.ch added a comment to D44411: sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9).

My first round of tests was all good, no regressions so far. I still have to test mmap'ed operation, probably tomorrow.

Wed, Mar 27, 4:54 PM

Mar 21 2024

dev_submerge.ch added a comment to D44411: sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9).

@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 21 2024, 4:08 AM

Mar 19 2024

dev_submerge.ch added a comment to D44411: sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9).

@dev_submerge.ch Does this patch build on your machine?

Mar 19 2024, 11:02 PM

Mar 16 2024

dev_submerge.ch added a comment to D44084: snd_hdspe(4): Only buffer_copy() audio data once..
In D44084#1010276, @br 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

Mar 16 2024, 1:02 AM

Feb 26 2024

dev_submerge.ch added a comment to D44084: snd_hdspe(4): Only buffer_copy() audio data once..

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 26 2024, 1:17 AM
dev_submerge.ch added a comment to D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..

I mean that it'd be more helpful to have a more descriptive message than " Implement sample rate selection in a more robust way".

Feb 26 2024, 1:00 AM
dev_submerge.ch requested review of D44084: snd_hdspe(4): Only buffer_copy() audio data once..
Feb 26 2024, 12:49 AM
dev_submerge.ch updated the summary of D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..
Feb 26 2024, 12:46 AM

Feb 25 2024

dev_submerge.ch added a comment to D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..

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 25 2024, 11:27 PM
dev_submerge.ch added inline comments to D43996: pcm.4: Fix lint warnings.
Feb 25 2024, 11:17 PM

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).

Feb 24 2024, 1:10 PM
dev_submerge.ch requested review of D44051: snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917..
Feb 24 2024, 12:45 PM

Feb 17 2024

dev_submerge.ch updated the diff for D43798: snd_hdspe(4): Optional unified pcm device..

Correct man page regarding number of channels for HDSPe AIO cards.

Feb 17 2024, 7:39 PM
dev_submerge.ch added a comment to D43798: snd_hdspe(4): Optional unified pcm device..
In D43798#1002381, @br 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 17 2024, 12:48 AM

Feb 14 2024

dev_submerge.ch added a comment to D43835: sched_setscheduler(2): Fix realtime privilege check.

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 14 2024, 11:52 AM

Feb 13 2024

dev_submerge.ch added a comment to D43835: sched_setscheduler(2): Fix realtime privilege check.

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 13 2024, 5:18 PM

Feb 11 2024

dev_submerge.ch added a comment to D43835: sched_setscheduler(2): Fix realtime privilege check.

Taken here from PR 276962.

Feb 11 2024, 3:47 PM
dev_submerge.ch requested review of D43835: sched_setscheduler(2): Fix realtime privilege check.
Feb 11 2024, 3:08 PM

Feb 10 2024

dev_submerge.ch accepted D43812: mixer(3): Do not hardcode "/dev/mixer".
Feb 10 2024, 5:02 PM
dev_submerge.ch accepted D43809: mixer(8): Use new mixer if we change the default unit.

Definitely an improvement, the previous behavior was confusing.

Feb 10 2024, 5:02 PM
dev_submerge.ch accepted D43796: mixer(8): Improve mute and recsrc controls.
Feb 10 2024, 12:34 AM
dev_submerge.ch accepted D43795: mixer.8: Fix wrong sentence.
Feb 10 2024, 12:32 AM
dev_submerge.ch accepted D43794: mixer(8): Allow full PCM device names as input for the -d option.
Feb 10 2024, 12:32 AM
dev_submerge.ch accepted D43793: mixer(8): Improve error messsages and warnings.
Feb 10 2024, 12:29 AM

Feb 9 2024

dev_submerge.ch accepted D43649: snd_uaudio.4: document sysctls.
Feb 9 2024, 11:17 PM
dev_submerge.ch added a comment to D43649: snd_uaudio.4: document sysctls.

One last thing, sorry for the mess of inline comments.

Feb 9 2024, 7:15 PM
dev_submerge.ch added a comment to D43793: mixer(8): Improve error messsages and warnings.

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.

Feb 9 2024, 7:01 PM
dev_submerge.ch added a comment to D43798: snd_hdspe(4): Optional unified pcm device..

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.

Feb 9 2024, 2:22 AM
dev_submerge.ch added a comment to D43649: snd_uaudio.4: document sysctls.

Ok, hopefully last round of comments from my side :-)

Feb 9 2024, 2:05 AM
dev_submerge.ch requested review of D43798: snd_hdspe(4): Optional unified pcm device..
Feb 9 2024, 12:17 AM

Feb 7 2024

dev_submerge.ch added inline comments to D43649: snd_uaudio.4: document sysctls.
Feb 7 2024, 8:05 PM

Feb 6 2024

dev_submerge.ch added a comment to D43767: snd_uaudio: skip duplicate configurations.

Integrated into D43679. The parameter iteration shouldn't produce duplicate entries anymore.

Feb 6 2024, 11:52 PM
dev_submerge.ch updated the diff for D43679: snd_uaudio(4): Fix config detection with defaults set..

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.

Feb 6 2024, 11:44 PM
dev_submerge.ch added a comment to D43649: snd_uaudio.4: document sysctls.

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.

Feb 6 2024, 3:24 PM
dev_submerge.ch added a comment to D43767: snd_uaudio: skip duplicate configurations.

The only case here is a duplicate sample rate, right?

For my device yeah, but I'm not sure if more sophisticated devices would print configs with multiple different channels or bits, which is why I added a check for channels and bits as well.

I'm uneasy to do this in the descriptor loop (why?).
I think it's much simpler and less invasive to integrate this with the changes in D43679. Would that be ok for you? I'll update it anyway today.

We could add an inner loop in uaudio_chan_fill_info() indeed. The reason I did it in the descriptor loop was so that we only check against valid values (the loop is placed after we've made sure the rate/channel/bit config is supported), whereas in uaudio_chan_fill_info() we'd get check against non-supported values as well.

That being said, even if we move the loop in uaudio_chan_fill_info(), I think it's better to have 2 separate patches as these patches are not directly related.

Feb 6 2024, 12:27 PM
dev_submerge.ch accepted D43766: snd_uaudio: mark selected configurations.

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().

Yeap, but that's still better than the current out-of-context dump, which requires one to have read the code to understand which config is selected. After all, this is printed during attach so it's expected that this reflects the state of the device during attach, and not runtime.

Feb 6 2024, 12:21 PM
dev_submerge.ch added a comment to D43767: snd_uaudio: skip duplicate configurations.

The only case here is a duplicate sample rate, right? I'm uneasy to do this in the descriptor loop (why?).

Feb 6 2024, 11:54 AM
dev_submerge.ch added a comment to D43766: snd_uaudio: mark selected configurations.

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 6 2024, 11:47 AM

Feb 4 2024

dev_submerge.ch added inline comments to D43679: snd_uaudio(4): Fix config detection with defaults set..
Feb 4 2024, 3:28 PM
dev_submerge.ch added a comment to D43679: snd_uaudio(4): Fix config detection with defaults set..

An example: My RME BabyFace has a 10 in 12 out channel configuration, and a 2 in 2 out channel configuration. Let's say I want to use the 2 in 2 out configuration because most audio applications cannot cope with 12 channels, and I can't route everything through Jack. I also have an SPL Crimson, 6 in 6 out. And I have a Focusrite Scarlett 18 in 20 out.

Current implementation: If I set default_channels=2, only the BabyFace is detected. I can set default_channels=6, and then I get both the BabyFace and the Crimson. But no way to use the Scarlett at the same time.

My proposal: I can set default_channels=2, and get all of them detected correctly. Caveat: Any other uaudio device with a 2 channel configuration will have that configuration selected.

We may need to make these sysctls per-device instead of global. I can take care of this if we agree to go ahead with it.

Feb 4 2024, 3:08 PM
dev_submerge.ch added a comment to D43679: snd_uaudio(4): Fix config detection with defaults set..

If the defaults can only take values between a certain range (i.e channels can be up to 64 and bits up to 32), and this patch also allows the driver to detect configs with higher values than the default, why don't we just start from the maximum value for both channels and bits instead of doing this hack, since we know that the default_*s are going to fall into those ranges anyway? Since in the iteration we try all possible combinations, we know that one of the configurations will end up being what the user would have defined using the defaults. This way we might not even need those controls at all. Also, following the same logic, do we need default_rate if the driver will only create channels for supported rates?

Correct me if I am missing something here, but I don't see where else those tunable values are used except in uaudio_chan_fill_info() which seems to search for and create configs for all supported channel/bits/rate combinations, and just includes a case where it tests if the user-supplied value is supported.

Feb 4 2024, 1:52 AM

Jan 31 2024

dev_submerge.ch added a comment to D43649: snd_uaudio.4: document sysctls.

Have a look at D43679 - that should make documentation of default_bits and default_channels easier.

Jan 31 2024, 4:23 PM
dev_submerge.ch added a comment to D43679: snd_uaudio(4): Fix config detection with defaults set..

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.

Jan 31 2024, 4:14 PM
dev_submerge.ch requested review of D43679: snd_uaudio(4): Fix config detection with defaults set..
Jan 31 2024, 3:50 PM
dev_submerge.ch added a comment to D43545: sound: Implement asynchronous device detach.

As communicated in private, the latest update to this change fixes all kernel panics and witness complaints.

Jan 31 2024, 3:33 PM

Jan 30 2024

dev_submerge.ch added a comment to D43649: snd_uaudio.4: document sysctls.

Now that I think about it, the "default_" prefix is kind of misleading. These variables act like a ceiling value, so maybe we should rename them to "max_"? snd_uaudio configures the channels, rate and bits by searching in descending order either from the default_ value or the maximum defined in the source code.

I think the default_ sysctl knobs would be more useful (and easier to document) if they actually acted like defaults. Would it be an option to improve the implementation in that way and handle them separately from the buffer_ms case?

Can you elaborate on what you mean by "separately"?

Jan 30 2024, 5:19 PM
dev_submerge.ch added a comment to D43649: snd_uaudio.4: document sysctls.

Now that I think about it, the "default_" prefix is kind of misleading. These variables act like a ceiling value, so maybe we should rename them to "max_"? snd_uaudio configures the channels, rate and bits by searching in descending order either from the default_ value or the maximum defined in the source code.

Jan 30 2024, 4:52 PM
dev_submerge.ch added a comment to D43545: sound: Implement asynchronous device detach.

Unfortunately I still get the kernel panic when I pull the USB plug, see inline comments.

Jan 30 2024, 2:50 PM
dev_submerge.ch added a comment to D43545: sound: Implement asynchronous device detach.

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
Jan 30 2024, 2:39 PM
dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Interesting. I just tested, and if I boot my machine while interface is on, kld_list and buffer_ms together do the trick. I mean, jack_iodelay reports exactly same latency as if I loaded the module, set buffer_ms and then turned on the interface. Maybe my interface is slow to respond initially, so sysctl has time to kick in?

Jan 30 2024, 3:11 AM · multimedia
dev_submerge.ch added a comment to D43649: snd_uaudio.4: document sysctls.

Thanks for picking this up, @christos.

Jan 30 2024, 2:18 AM

Jan 29 2024

dev_submerge.ch requested review of D43659: snd_hdspe(4): Per device sysctl for sample rate..
Jan 29 2024, 11:48 PM

Jan 28 2024

dev_submerge.ch added a comment to D43545: sound: Implement asynchronous device detach.

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 28 2024, 11:40 PM
dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

@christos: Thanks! Since @mav didn't participate here, would someone else be so kind to commit this? Unless there's other issues that weren't brought up yet.

Jan 28 2024, 3:51 PM · multimedia

Jan 27 2024

dev_submerge.ch added a comment to D43527: snd_hdspe(4): Per device sysctl for period..

Could you commit it if there are no other issues? Thank you!

Jan 27 2024, 2:17 PM
dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

I didn't answer about re-plugging. No, the interface is always connected and I don't touch the cables.

Jan 27 2024, 2:02 PM · multimedia

Jan 25 2024

dev_submerge.ch added a comment to D43545: sound: Implement asynchronous device detach.

Jackpot again! ;-)
This time it's a different problem, see inline comment.

Jan 25 2024, 12:22 AM

Jan 24 2024

dev_submerge.ch added a comment to D43545: sound: Implement asynchronous device detach.

Jackpot! Kernel panic on the first attempt! ;-)
See inline comment, don't have an explanation yet why this happens there.

Interesting, I'll have to investigate this.

What did you do to reproduce it?

Jan 24 2024, 1:33 AM
dev_submerge.ch added a comment to D43545: sound: Implement asynchronous device detach.

Jackpot! Kernel panic on the first attempt! ;-)
See inline comment, don't have an explanation yet why this happens there.

Jan 24 2024, 12:44 AM

Jan 22 2024

dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Meka, according to USB descriptor your audio interface is fine with 1ms intervals (bInterval = 0x0004). So that's not the problem. And the latency doesn't even change without this patch, we know that worked before. Did you replug the device after you changed the buffer_ms sysctl? New buffer_ms values may not become effective immediately, depending on your settings.

Jan 22 2024, 4:38 PM · multimedia

Jan 21 2024

dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Thanks for all the measurements, Meka! It seems like the buffer_ms sysctl doesn't have any effect at all. I suspect your audio interface to demand a longer interval in its USB descriptor. Could you

Jan 21 2024, 7:18 PM · multimedia

Jan 20 2024

dev_submerge.ch added a comment to D43527: snd_hdspe(4): Per device sysctl for period..

@br I changed the default period from 128 to 256, compared to the port version of snd_hdspe_alt. That should be closer to the playback blocksize given by the pcm latency settings by default. Could you please test this in your HDSPe AIO setup and make sure the system defaults (vchanformat=s16le:2.0, vchanrate=48000, latency=2, latency_profile=1) work fine?

Jan 20 2024, 7:52 PM
dev_submerge.ch requested review of D43527: snd_hdspe(4): Per device sysctl for period..
Jan 20 2024, 7:12 PM
dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Hi Meka, sorry to hear, hope you are well now.
Your measurements seem to be accurate. Unfortunately they do not match my expectations, as I would have estimated more like a ~12ms reduction in this scenario.
I'll try to verify my own tests, but could you measure the new default of buffer_ms=4 in your setup? And a period of 768 in addition to 512 and 1024? Thanks!
I may have to check with the version of Jack in ports, I did my measurements with the new sosso backend which does mmap io.

Jan 20 2024, 1:10 AM · multimedia

Jan 19 2024

dev_submerge.ch updated the diff for D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Clarified buffer_ms sysctl description as suggested by @emaste.

Jan 19 2024, 12:28 AM · multimedia

Jan 18 2024

dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

@meka_tilda.center Any comment on your test results?

Jan 18 2024, 8:50 PM · multimedia
dev_submerge.ch updated the diff for D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Introduced UAUDIO_BUFFER_MS_MIN and UAUDIO_BUFFER_MS_MAX as constants.
Intentionally left the comments that mention 8 ms max buffer length. It
gives some understandable context and that value will probably never change
as long as current USB audio standards are supported.

Jan 18 2024, 8:15 PM · multimedia

Jan 17 2024

dev_submerge.ch added a comment to D43467: sound: use device_set_descf() to set device descriptions.

Please note that this commit depends on rGd7fde2c9eccf, and thus also on rGb6052c10fb4ad. These were not marked for MFC. Don't know much about MFC procedures, but cherry-picking this commit without the others will probably fail. Feel free to MFC them as well if needed.

Jan 17 2024, 1:25 AM
dev_submerge.ch accepted D43467: sound: use device_set_descf() to set device descriptions.

Looks good to me, /dev/sndstat output is

Jan 17 2024, 12:39 AM

Jan 14 2024

dev_submerge.ch updated the diff for D43393: snd_hdspe(4): One pcm device per physical ADAT port..

Fixed various style(9) issues.

Jan 14 2024, 12:38 AM

Jan 12 2024

dev_submerge.ch added a comment to D43393: snd_hdspe(4): One pcm device per physical ADAT port..

Thanks. I'll fix the style(9) issues you mentioned and some more that I just spotted now - probably tomorrow.

Jan 12 2024, 7:24 PM

Jan 11 2024

dev_submerge.ch added a comment to D43393: snd_hdspe(4): One pcm device per physical ADAT port..

Regarding future support of additional RME cards, I looked briefly into that when I decided for the bitset approach on physical ports. Obviously there's a limit to that (32 bits). But physical ports on the AIO Pro look like the same as AIO, MADI FX has 5 ports and the others have even less. Thus I wouldn't worry too much about this limit, we may have to adapt more aspects of the driver anyway. The linux driver for example handles MADI and AES in separate files from AIO and RayDAT.

Jan 11 2024, 4:28 PM

Jan 10 2024

dev_submerge.ch added a comment to D43393: snd_hdspe(4): One pcm device per physical ADAT port..

Tested on 15.0-CURRENT as of 2024-01-09, on amd64 with an RME HDSPe RayDAT card. I have this code in use for several months now, as a separate kernel module from ports.

Jan 10 2024, 7:02 PM
dev_submerge.ch requested review of D43393: snd_hdspe(4): One pcm device per physical ADAT port..
Jan 10 2024, 5:50 PM

Jan 4 2024

dev_submerge.ch updated the diff for D43252: snd_hdspe(4): Add sysctl settings for clock source..
  • Should be all tabs now between #define and macros.
    • Table lookup instead of magic number 15 for clock_source sysctl.
    • Moved clock source setting register value creation to tables in hdspe.c.
    • Simplified and cleaned up clock source related macros.
    • Removed unused and invalid HDSPM_CLOCK_MODE_MASTER macro.
Jan 4 2024, 12:00 AM

Jan 2 2024

dev_submerge.ch added a comment to D43252: snd_hdspe(4): Add sysctl settings for clock source..

I'll fix up the patches tomorrow, see inline comments.

Jan 2 2024, 3:25 PM

Dec 31 2023

dev_submerge.ch updated the diff for D43252: snd_hdspe(4): Add sysctl settings for clock source..

Fix minor readability and style(9) issues.

Dec 31 2023, 5:24 PM

Dec 30 2023

dev_submerge.ch added a comment to D43252: snd_hdspe(4): Add sysctl settings for clock source..

This is part of the improvements developed on github as an alternative kernel module for HDSPe sound cards. I built that separately as a local port / package. As such these changes have been tested extensively with a HDSPe RayDAT card, and are in use for several months now.

Dec 30 2023, 8:47 PM
dev_submerge.ch requested review of D43252: snd_hdspe(4): Add sysctl settings for clock source..
Dec 30 2023, 7:40 PM
dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Thanks for testing, Meka! Could you elaborate on how you did the latency measurements?
Because jack_iodelay reports a decrease of only ~2ms in total roundtrip latency, whereas the extra loopback latency decreases by ~300 frames (~6ms at 48kHz). Any other changes in the setup or Jack settings?

Dec 30 2023, 1:12 PM · multimedia

Nov 24 2023

dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

Ping! Also, patch briefly tested on 15.0-CURRENT as of today. No regressions, works as expected.

Nov 24 2023, 2:41 PM · multimedia

Sep 23 2023

dev_submerge.ch added a comment to D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..

@mav I hope it's ok to add you as a reviewer / committer here? Or should I ask someone else instead?

Sep 23 2023, 2:58 PM · multimedia
dev_submerge.ch added a reviewer for D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable.: mav.
Sep 23 2023, 2:49 PM · multimedia
dev_submerge.ch updated the test plan for D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..
Sep 23 2023, 2:22 PM · multimedia

Sep 22 2023

dev_submerge.ch added a comment to D41627: Lower minimal USB audio buffer size limit from 2ms to 1ms.

FYI, my patch is here D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable. for review. I'll add more info this weekend.

Sep 22 2023, 3:04 PM · multimedia
dev_submerge.ch requested review of D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable..
Sep 22 2023, 2:44 PM · multimedia

Sep 12 2023

dev_submerge.ch added a comment to D41627: Lower minimal USB audio buffer size limit from 2ms to 1ms.

Update: Looks like the current snd_uaudio implementation actually does transfers according to USB standard, it spreads the isochronous frames over the whole transfer interval. I was misled by parts of the code, and the fact that usbdump(8) only shows the first millisecond of longer transfers. Sorry for the noise.

Sep 12 2023, 12:13 AM · multimedia

Sep 4 2023

dev_submerge.ch added a comment to D41627: Lower minimal USB audio buffer size limit from 2ms to 1ms.

I didn't promise it to be easy, but I think USB transfer size should be as close to sound(4) fragment size, if it can't be equal, as for other sound cards.

Sep 4 2023, 1:03 PM · multimedia

Sep 3 2023

dev_submerge.ch added a comment to D41627: Lower minimal USB audio buffer size limit from 2ms to 1ms.

Well, these are three different topics then:

Sep 3 2023, 7:08 PM · multimedia
dev_submerge.ch added a comment to D41627: Lower minimal USB audio buffer size limit from 2ms to 1ms.

After some thought I have a different proposal:

Sep 3 2023, 12:53 PM · multimedia

Sep 1 2023

dev_submerge.ch added a comment to D41627: Lower minimal USB audio buffer size limit from 2ms to 1ms.

Chiming in here as I have some experience with the snd_uaudio module and its code. I do support this change, but I think the title is a bit misleading.

Sep 1 2023, 11:50 PM · multimedia