Differential D46253
mixer(8): Implement hot-swapping Authored by christos on Aug 9 2024, 6:07 PM. Tags None Referenced Files
Subscribers
Details Introduce a -V option, which can be used alongside -d (default unit Sponsored by: The FreeBSD Foundation
Diff Detail
Event TimelineComment Actions Ideally we could detect the control device automatically, but since there is no way to do this, the best we can do is at least provide it manually. This way we can avoid manually writing the virtual_oss_cmd(8) by hand each time we issue a default unit change and we want to hot-swap at the same time. Comment Actions Good idea. But it wasn't immediately clear to me how it works and when to use it.
Comment Actions I know it's kind of tedious and maybe hard to understand at first, but as I said in my initial comment, I don't think we can make this simpler if we don't have a way to know what the virtual_oss control device is, so at least for now this option is a necessary evil. Comment Actions Not only that, there's also the case when the user does not want virtual_oss to run on the (new) default pcm device, in a more static virtual_oss setup for example. BTW, what happens when a virtual_oss provided pcm device is selected as default device? I don't have much experience with virtual_oss. Comment Actions If I understand correctly, you mean what will happen if say, we change the default device to dsp1, but we do not want virtual_oss to use dsp1 as well with this change. In this case we can simply not use the -V option and use just -d normally. Or do you mean something different?
mixer(8)'s -d option accepts either an integer representing the sound(4) device unit, or a "pcmX" string (and extracts X), and then calls hw.snd.default_unit, so I don't think there's a problem here. This unit number is also used to form the /dev/dspX string passed as the new playback/recording device to virtual_oss_cmd(8) when the -V option is specified. So the only edge-case I can think of is when the virtual_oss device named to something like dsp1, in which case the device node will be /dev/dsp1. In this case, mixer_set_dunit() will fail because this unit number does not correspond to a sound(4) device, and virtual_oss_cmd will also fail to use this device (from what I can see it only accepts sound(4) devices): root@freebsd:~ # virtual_oss -T /dev/sndstat -S -C 2 -c 2 -r 48000 -b 16 -s 1024 -f /dev/dsp0 -d dsp1 -t vdsp.ctl & root@freebsd:~ # virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp1 virtual_oss: Could not open DSP device '/dev/dsp1': Invalid argument root@freebsd:~ # mixer -d1 -V /dev/vdsp.ctl:all mixer: cannot set default unit to 1: Invalid argument virtual_oss: Could not open DSP device '/dev/dsp1': Invalid argument
Comment Actions Yes, I meant that the -V flag is actually a necessity to make it optional, since we neither know which pcm device virtual_oss currently uses, nor whether the user intends to change that. So implementation is fine, I just wanted the man page to explain the use case more explicitly, as in your latest changes.
Good, thanks for checking. While we're at it, this only supports one instance of virtual_oss, right? Also virtual_oss(8) suggests to create a /dev/dsp device to make virtual_oss the default. That overrides the sysctl default unit. I think we should check that and issue a warning with the -d flag, as it has no effect in that case.
Comment Actions A single command yes, because we can pass only a single virtual_oss control device to -V, but if you want you can run the same command with the same -d argument, but different control devices multiple times and it should work fine. The -d option won't take effect because the default unit is already changed but the -V option will change the device virtual_oss uses. Something like this: # mixer -dpcm1 -V /dev/vdsp1.ctl # mixer -dpcm1 -V /dev/vdsp2.ctl
I do not think it overrides the default unit. It turns off hw.snd.basename_clone, so that sound(4) disables access to the /dev/dsp node, in order for virtual_oss to create an actual /dev/dsp device. This is done so applications can still open /dev/dsp as they would normally, but in reality they open the virtual_oss device. It's a hack I guess.
Comment Actions Execute mixer_set_dunit() before doing virtual_oss stuff. Comment Actions As you explain, if /dev/dsp is created by virtual_oss, then setting the hw.snd.default_unit sysctl has no effect. Applications will open the virtual_oss device. Since we're integrating mixer(8) with virtual_oss here, I think we should issue a warning in that case. It's not obvious to the user. Could be done in a separate patch though. Comment Actions Well, it has an effect, but it's visible when hw.snd.basename_clone is set again (assuming it is unset in the first place). Also keep in mind that virtual_oss might not necessarily be running as /dev/dsp, in which case hw.snd.basename_clone will not be touched by virtual_oss, so this warning would be false. There can be a case where virtual_oss is running with a device name other than /dev/dsp (and the application has that device open), but uses the default device for playback/recording. In this case, the warning will be false because /dev/dsp will point to the new default device, and virtual_oss will also be re-configured to use the new one as well. I also edited the man page comment about virtual_oss running on the default PCM device (didn't update the diff here). This should work even if it doesn't run on the default. For example, suppose we have created a virtual_oss device in /dev/foobar, which uses /dev/dsp0 (let's say it's the default) for playback and recording. So in this case, /dev/dsp is still from sound(4) and hw.snd.basename_clone should be set. If we issue a mixer -dpcm1 -V /dev/vdsp.ctl, we will change the default unit to pcm1, and virtual_oss will also switch to /dev/dsp1, even though it's not running as /dev/dsp, and we'll start getting output from pcm1 from the application using that virtual_oss device. Comment Actions I know all this. How do I rephrase it... A user issues mixer -d pcm1. Can we agree on the following:
I'd like mixer(8) to print a warning message to the user under those conditions.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||