Re: Where's f_audioctx set?
On Tue, 13 Jul 2021, Mouse wrote: However, the KASSERT, combined with AUDIO_SETINFO doing something, indicates that it clearly is getting set. So, I'm obviously missing something. What? I had need to look into the audio code some time back, so I think I can explain this: audio_open() in audio.c: 1. fills audio_file_t *af; 2. calls fd_allocfile(, ); 3. does fd_clone() with `af' as last param; 4. fd_clone() does fp->f_data = af; 5. f_data is just f_undata.fd_data And, since f_undata is a union, step 4 sets fd_audioctx. -RVP
re: Where's f_audioctx set?
i'm not sure, but i'm guessing that it happens here: audio.c:2491: error = fd_clone(fp, fd, flags, _fileops, af); audio.c:3541: error = fd_clone(fp, fd, flags, _fileops, af); audio.c:8167: error = fd_clone(fp, fd, flags, _fileops, af); with kern_descrip.c:1882:fd_clone(file_t *fp, unsigned fd, int flag, const struct fileops *fops, kern_descrip.c:1883: void *data) [ ... ] kern_descrip.c:1895: fp->f_data = data; .mrg.
Re: Where's f_audioctx set?
>> However, the KASSERT, combined with AUDIO_SETINFO doing something, >> indicates that it clearly is getting set. So, I'm obviously missing >> something. >> What? > I had need to look into the audio code some time back, so I think I > can explain this: > audio_open() in audio.c: > 1. fills audio_file_t *af; > 2. calls fd_allocfile(, ); > 3. does fd_clone() with `af' as last param; > 4. fd_clone() does fp->f_data = af; > 5. f_data is just f_undata.fd_data > And, since f_undata is a union, step 4 sets fd_audioctx. Oh, ick. (This causes all fields of f_undata other than fd_data, or, possibly, other void * fields - I'd have to think about that - to go undefined, as in accessing them produces undefined behaviour. I'm slightly surprised undefined-behaviour detectors haven't been kicking up a fuss.) Thank you for explaining! /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Audio volume setting: not working - sometimes?
>>> The primary gain control might not be the one currently responsible
>>> for output volume depending on the various DACs available.
>> Possibly - but audioctl's play.gain field _does_ work to control the
>> output volume. I had thought audioctl's play.gain was just a
>> different interface to the same thing [...]
> audioctl is primarily for manipulating /dev/sound, which persists
> these settings between opens, whereas /dev/audio doesn't. audioctl
> works by performing SETINFO on /dev/audioctl.
Right. This has nothing to do with the issue at hand. In the
problematic case, userland opens /dev/audio0 and tries to set the
playback gain (to 254). This setting is ignored, according to both the
resulting signal and audioctl -a (run while the application still has
/dev/audio0 open).
> If you need the "audio device parameters persist between opens"
> feature I'd recommend using /dev/sound instead.
Persistence between opens is neither wanted nor relevant.
Today I had the leisure to track this down. Building a kernel with
AUDIO_DEBUG and setting hw.audio0.debug to 2, I saw au_set_gain lines
indicating that the volume was getting changed as specified, only to be
immediately - as in, the next log line - changed back.
Turns out that, if you specify play.gain and play.balance in the same
AUDIO_SETINFO call, the former is ignored:
static int
audio_hw_setinfo(struct audio_softc *sc, const struct audio_info *newai,
struct audio_info *oldai)
{
u_int pgain;
...
/* Backup play.{gain,balance} */
if (SPECIFIED(newpi->gain) || SPECIFIED_CH(newpi->balance)) {
au_get_gain(sc, >sc_outports, , );
if (oldai) {
oldpi->gain = pgain;
oldpi->balance = pbalance;
}
}
/* Backup record.{gain,balance} */
if (SPECIFIED(newri->gain) || SPECIFIED_CH(newri->balance)) {
...
}
if (SPECIFIED(newpi->gain)) {
error = au_set_gain(sc, >sc_outports,
newpi->gain, pbalance);
if (error) {
...
}
}
if (SPECIFIED(newri->gain)) {
...
}
if (SPECIFIED_CH(newpi->balance)) {
error = au_set_gain(sc, >sc_outports,
pgain, newpi->balance);
Note that pgain is not changed between the "Backup play.{gain,balance}"
code and the last au_set_gain above, even if newpi->gain is specified.
Changing userland to call AUDIO_SETINFO twice, once with balance
specified and once with gain specified, is a workaround for my
purposes.
PR filed - kern/56308.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: kern.maxlockf for byte range lock limit
On Tue, Jul 13, 2021 at 06:37:57AM +, Emmanuel Dreyfus wrote: > On Tue, Jul 13, 2021 at 03:36:49AM +, David Holland wrote: > > Well, that was the idea; make it some factor times the current open > > file limit or something like that. Not sure why the existing limit is > > apparently per-user rather than per-process or what that's supposed to > > accomplish. These lock objects are not exactly large so it's not > > necessary to be tightfisted with them. > > Then we could just use maxfiles, coulnd't we? You should be able to have multiple locks per file, but the whole point of the limit was that shouldn't be able to trivially exhaust kernel memory. Joerg
Where's f_audioctx set?
I started to look into the audio setting issue I mentioned here a couple of weeks ago (thread topic "Audio volume setting: not working - sometimes?"). (9.1, amd64.) Right away I ran into something I don't understand. The implementation of AUDIO_SETINFO calls audio_file_setinfo with, among other things, a variable called file. file is passed in from the caller, which gets it from KASSERT(fp->f_audioctx); file = fp->f_audioctx; However, I have completely failed to figure out where f_audioctx is set. I find exactly one assignment to f_audioctx in the entire kernel source tree, that being fp->f_audioctx = NULL; f_audioctx is #defined to f_undata.fd_audioctx, but fd_audioctx occurs only twice in the whole tree: struct audio_file *fd_audioctx; // DTYPE_MISC (audio) #define f_audioctx f_undata.fd_audioctx However, the KASSERT, combined with AUDIO_SETINFO doing something, indicates that it clearly is getting set. So, I'm obviously missing something. What? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: kern.maxlockf for byte range lock limit
On Tue, Jul 13, 2021 at 03:36:49AM +, David Holland wrote: > Well, that was the idea; make it some factor times the current open > file limit or something like that. Not sure why the existing limit is > apparently per-user rather than per-process or what that's supposed to > accomplish. These lock objects are not exactly large so it's not > necessary to be tightfisted with them. Then we could just use maxfiles, coulnd't we? -- Emmanuel Dreyfus m...@netbsd.org
