Re: sndiod: Cannot change bit depth and sample rate

[Alexandre Ratchov]

On Sun, Jul 28, 2024 at 11:39:17PM +0200, rfab...@mhsmail.ch wrote:
> 
> `$ rcctl get sndiod`
> As expected:
> 
> sndiod_class=daemon
> sndiod_execdir=
> sndiod_flags=-f rsnd/1 -m play -e s24 -r 96000

The -r and -e options are device properties, so they must precede the
-f option that adds the device. Try this:

rcctl set sndiod flags -e s24 -r 96000 -f rsnd/1 -m play

This is because there may be multiple devices with different
parameters. See the last paragraphs of the DESCRIPTION section of
sndiod(8).

Re: M-Audio Fast Track Ultra 8R

[Alexandre Ratchov]

On Sun, Jun 30, 2024 at 08:26:06AM +0200, Jan Stary wrote:
> This is current/amd64 on a PC (full dmesg below).
> I got my hands on an M-Audio Fast Track Ultra 8R,
> an USB audio interface; eight tracks, 24/96, nice.
> 
> It doesn't seem to be supported though:
> it attaches as an ugen, but no uaudio.
> 
> umidi0 at uhub4 port 2 configuration 1 interface 3 "M-Audio Fast Track Ultra 
> 8R" rev 2.00/1.51 addr 3
> umidi0: (genuine USB-MIDI)
> umidi0: out=1, in=1
> midi0 at umidi0: 
> ugen0 at uhub4 port 2 configuration 1 "M-Audio Fast Track Ultra 8R" rev 
> 2.00/1.51 addr 3
> 
> This happens in any USB slot.
> 
> What can I do to debug this?
> Is anyone using this on OpenBSD?
> 
> It is an USB-compliant audio device,
> macOS and Windows use it just fine.

It seems that the uaudio driver doesn't even try to attach. You could
instrument the uaudio_match() kernel function, and try to figure out
why it returns UMATCH_NONE for your device.

Re: make usb audio device always rsnd/1 - not rsnd/2

[Alexandre Ratchov]

On Wed, Jun 19, 2024 at 01:25:44PM +0200, Divan Santana wrote:
> Greetings All,
> 
> I have a USB audio bluetooth dongle plugged in.
> 
> azalia0 at pci0 dev 31 function 3 "Intel 600 Series HD Audio" rev 0x01: msi
> audio0 at azalia0
> uaudio0 at uhub5 port 1 configuration 1 interface 3 "Creative Creative BT-W5" 
> rev 2.00/10.00 addr 7
> uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 3 ctls
> audio1 at uaudio0
> 
> I also have a usb camera plugged in.
> 
> uaudio1 at uhub1 port 6 configuration 1 interface 3 "Logitech C270 HD WEBCAM" 
> rev 2.00/0.21 addr 9
> uaudio1: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls
> audio2 at uaudio1
> 
> To use this bluetooth audio device I do:
> 
> doas rcctl set sndiod flags -f rsnd/0 -F rsnd/1
> 
> Sometimes upon rebooting these devices switch device numbers.  This
> makes the above sndiod flags no longer valid.
> 
> How can one make "Creative Creative BT-W5" device always rsnd/1 and not
> sometimes rsnd/2?
> 

Not yet.

Not exactly what you asked for, but you could try the audio/sndiokeys
port. It allows you to circulate through your audio devices with X
hot-keys. For instance, start "sndiokeys -D" and hit Ctrl-Alt-0 util
you hear a short "beep" on the desired device. Not perfect, but less
painful than running sndioctl(1) or restarting sndiod(8).

HTH

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Alexandre Ratchov]

On Sat, May 25, 2024 at 09:13:56AM +, Ali Farzanrad wrote:
> 
> Even when azalia is disabled my system gets sudden reboots.
> First sudden reboot was just after playing a music; but next 2 reboots
> was happened without playing anything.
> 

This suggests the reboots are not directly caused by the azalia's msi
vs old-style interrupts.

I'd suggest that you find and old enough snapshot (or release) that
used to work reliably on this machine and make sure it still works
reliably with the old software version. Not just an hour, use it few
days for real work.

This would confirm that the hardware is still OK. Take few quick notes
of what devices are involved, how the machine is used, etc. Save the
dmesg.

If this isn't a hardware problem, then grab a new snapshot and try to
understand what changed, compare the dmesg, compare the usage pattern
etc. Possibly start bissecting the kernel until you find the change
that causes the reboots.

HTH

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Alexandre Ratchov]

On Fri, May 24, 2024 at 09:04:29PM +, Ali Farzanrad wrote:
> Alexandre Ratchov  wrote:
> > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote:
> > > Hi again,
> > > 
> > > During my tests it seems that this version of kernel works fine:
> > > 
> > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
> > > 
> > > But this version of kernel will cause sudden reboots without any kernel
> > > panic or message after 5-60 minutes in my Minisforum UM790:
> > > 
> > > # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
> > > 
> > > After investigation I found this patch could fix my problem:
> > > 
> > > Index: azalia.c
> > > ===
> > > RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
> > > diff -u -p -r1.287 azalia.c
> > > --- azalia.c  17 May 2024 19:43:45 -  1.287
> > > +++ azalia.c  24 May 2024 16:26:38 -
> > > @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
> > >   azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
> > >   }
> > >  
> > > + /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
> > > + if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
> > > + switch (PCI_PRODUCT(sc->pciid)) {
> > > + case PCI_PRODUCT_AMD_17_HDA:
> > > + case PCI_PRODUCT_AMD_17_1X_HDA:
> > > + case PCI_PRODUCT_AMD_HUDSON2_HDA:
> > > + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
> > > + }
> > > + }
> > > +
> > >   /* interrupt */
> > >   if (pci_intr_map_msi(pa, &ih) && pci_intr_map(pa, &ih)) {
> > >   printf(": can't map interrupt\n");
> > > 
> > > However it breaks my front 3.5mm audio port and I should use my
> > > USB-to-3.5mm audio port adapter again.
> > > 
> > > How may I investigate more?
> > > 
> > 
> > could you confirm that the system reboots only while you're using the
> > azalia device?
> 
> I disabled sndiod, and unplugged my USB-to-3.5mm audio adapter and also
> unplugged front 3.5mm audio port, then reboot my OpenBSD and waited on
> xenodm login screen for few minutes; most of the time it reboots in
> less than 10 minutes... without any interaction from me, or playing
> anything...
> 

Could you disable the azalia driver and redo your test? reboot, then
on the boot(8) prompt type "boot -c", then "disable azalia", then
"quit".

Then, just do your regular stuff and see if the system reboots.

Re: Sudden reboot every 5-10 minutes on latest snapshot

[Alexandre Ratchov]

On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote:
> Hi again,
> 
> During my tests it seems that this version of kernel works fine:
> 
> # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 19:30" -P src
> 
> But this version of kernel will cause sudden reboots without any kernel
> panic or message after 5-60 minutes in my Minisforum UM790:
> 
> # TZ=UTC cvs -Qd /cvs get -D "2024-05-17 20:00" -P src
> 
> After investigation I found this patch could fix my problem:
> 
> Index: azalia.c
> ===
> RCS file: /home/cvs/src/sys/dev/pci/azalia.c,v
> diff -u -p -r1.287 azalia.c
> --- azalia.c  17 May 2024 19:43:45 -  1.287
> +++ azalia.c  24 May 2024 16:26:38 -
> @@ -557,6 +557,16 @@ azalia_pci_attach(struct device *parent,
>   azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
>   }
>  
> + /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
> + if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
> + switch (PCI_PRODUCT(sc->pciid)) {
> + case PCI_PRODUCT_AMD_17_HDA:
> + case PCI_PRODUCT_AMD_17_1X_HDA:
> + case PCI_PRODUCT_AMD_HUDSON2_HDA:
> + pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
> + }
> + }
> +
>   /* interrupt */
>   if (pci_intr_map_msi(pa, &ih) && pci_intr_map(pa, &ih)) {
>   printf(": can't map interrupt\n");
> 
> However it breaks my front 3.5mm audio port and I should use my
> USB-to-3.5mm audio port adapter again.
> 
> How may I investigate more?
> 

could you confirm that the system reboots only while you're using the
azalia device?

when you apply above diff, is audio unstable or it doesn't work at
all?

Re: sndioctl not switching device in 7.5 and current

[Alexandre Ratchov]

On Tue, Apr 23, 2024 at 04:32:12PM -0300, Thanos Tsouanas wrote:
> 
> So, the good news is that it seems to be a hardware problem:
> I installed 7.4 on a usb stick just to test it and it did
> work, but when I booted back to the same 7.5 that it didn't,
> it was recognized properly this time, to my surprise:
> 
> uaudio0 at uhub3 port 3 configuration 1 interface 3 "JDS Labs Inc JDS
> Labs DAC" rev 1.10/0.01 addr 7
> uaudio0: class v1, full-speed, sync, channels: 2 play, 0 rec, 3 ctls
> audio1 at uaudio0
> 
> ...and worked perfectly well.
> 
> Plugging it in and out I notice that: *most* of the times it's
> recognized as 0 play channels, sometimes as 2 play channels,
> and sometimes not even seen by the kernel at all.
> 
> I guess it's safe to assume that it's a hardware problem?
> 

I don't know, does it fail the same way on openbsd 7.4? (or other
operating systems?)

> After this, let me know if it still makes sense to run the
> program you sent and share the output.  (I suppose the diff
> you sent was to change uaudio back to 7.4's version?)
> 

No, the diff attemps to fix a bug that makes certain devices with
multiple interfaces to (always) fail.

Re: sndioctl not switching device in 7.5 and current

[Alexandre Ratchov]

On Mon, Apr 22, 2024 at 01:14:43PM -0300, Thanos Tsouanas wrote:
> Hello,
> 
> I have just sysupgraded from 7.4 to 7.5 on my thinkpad X1C9
> in which I was using an external audio interface (OL DAC by
> JDS Labs), but I cannot get it to work anymore.
> 
> Using sndioctl to change server.device from 0 to 1 gives the
> impression that it worked (no error shown and its output
> indicates success), but as soon as check sndioctl's output
> it's back to server.device=0:
> 
> # sndioctl server.device=1
> server.device=1
> # sndioctl server.device
> server.device=0
> 
> dmesg shows nothing relevant, and I was not able to find any
> error logged under /var/log files.  (Should I be looking
> somewhere else for sndiod/sndioctl error messages?)
> 
> My audio interface is recognized by the 7.5 kernel:
> 
> uaudio0 at uhub1 port 1 configuration 1 interface 3 "JDS Labs Inc JDS
> Labs DAC" rev 1.10/0.01 addr 7
> uaudio0: class v1, full-speed, sync, channels: 0 play, 0 rec, 3 ctls


0 channels seems wrong.  So, you confirm that this device used to work?

Re: aucat options parsing

[Alexandre Ratchov]

On Thu, Mar 21, 2024 at 10:10:03AM +0100, Jan Stary wrote:
> On Mar 21 10:07:08, h...@stare.cz wrote:
> > This seems strange:
> > 
> > $ aucat -n -d -i input.wav -c -r 8000 -o out.wav  
> > input.wav: skipped unknown chunk
> > input.wav: play, chan 0:3, 48000Hz, s16le, bytes 80..1920080, vol 8388608
> > -r: channel range expected
> > 
> > It is an ommited number in -c 1 of course,
> > not a missing sample rate.
> 
> Sorry, my bad; it is a missing channel range of course.
> Without using the new -m, it seems that one _must_
> use the old -c syntax of -c lo:hi; in particular,
> 
>   -c 1 -o out.wav
> 
> is illegal, even though it is a valid (new) syntax.
> If that is the case, shouild the manpage mention that?
> 

'-c 1' is the right syntax for all cases. The old syntax (-c lo:hi)
still works only to not break existing scripts until they are updated.
It is not documented anymore.

Re: No audio playback with azalia0 Intel Braswell HD Audio

[Alexandre Ratchov]

On Mon, Feb 05, 2024 at 08:28:16PM -0800, jrmu wrote:
> Greetings,
> 
> I am attempting to play audio on an HP Chromebook 11 G5 Setzer,
> but OpenBSD appears to be missing the necessary codecs. Are there any
> workarounds? I'm guessing that switching from the built-in speakers to
> headphones won't make any difference. Any suggestions appreciated.
> 

You could build a kernel with AZALIA_DEBUG and figure out  why the codec is
not supported.

> azalia0 at pci0 dev 27 function 0 "Intel Braswell HD Audio" rev 0x35: msi
> azalia0: no supported codecs

Re: how to play bytebeat on openbsd?

[Alexandre Ratchov]

On Mon, Feb 05, 2024 at 02:21:17PM +0100, Alexandre Ratchov wrote:
> Play the result:
> 
> ./a.out | aucat -e u8 -c 0:1 -r 8000 -i -
^^^

should be "-c 0:0", but "-c 0:1" may also make sense for certain one-liners
;-)

Re: how to play bytebeat on openbsd?

[Alexandre Ratchov]

On Fri, Feb 02, 2024 at 06:41:46PM -, beecdadd...@danwin1210.de wrote:
> hello
> 
> I've tried for hours to play bytebeat as everyone else
> 
> I cannot find anything on the entire internet
> 
> all I got is `cat a.out >> /dev/speaker)` as root.. a.out is compiled code , a
> loop and `putchar(t*((t>>12|t>>8)&63&t>>4));`.. this doesn't sound nearly the
> same as it does to other people
> it's also slow, not fast
> 

You've to compile the bytebeat program, run it and send the result to a
program that will play can play usinged 8-bit mono at 8kHz.  aucat(1) can do
this.

Example, create a bytebeat.c file with your one-liner and the proper C
boilerplate:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

#include 

int main(void)
{
int t;

for (t = 0; t < 8; t++) {
putchar(t*((t>>12|t>>8)&63&t>>4));
}

return 0;
}

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Build it:

cc -Wall bytebeat.c

Play the result:

./a.out | aucat -e u8 -c 0:1 -r 8000 -i -

Or save it a as music.wav so you can futher process it and/or send it to
someone:

./a.out | aucat -e u8 -c 0:0 -r 8000 -i - -n -o music.wav

HTH

Re: my first patch

[Alexandre Ratchov]

On Tue, Oct 24, 2023 at 10:42:06PM +0200, Jan Stary wrote:
> On Oct 24 22:09:02, a...@caoua.org wrote:
> > faad -w file.m4a | cat >file.wav
> > results in a file with zero-size data chunk (because faad couldn't
> > seek to the beginning of the file to fixup the header). aucat,
> > audacious, audacity and sox can't play it; mpv, and ffplay can
> 
> SoX's play --ignore-length can play it.
> 

excellent! thank you

Re: my first patch

[Alexandre Ratchov]

On Tue, Oct 24, 2023 at 11:11:01PM +0600, Maria Morisot wrote:
> 
> Forgive me if I'm dense, but I'm a better artist than I am a
> programmer. I'm trying to follow you though. I understand why you
> cannot seek in a pipe, but I do not understand why that affects
> playback of a MS Wav file through a pipe.

There are two reasons:

First, the .wav file may have many headers, in any order, and one data
chunk. aucat has to parse certain headers (ex. to extract the data
format and its size) and skip others (unused meta data). Currently, it
uses lseek(2) to move the file pointer from one header to another and
to move to the data location to start reading.

This is how .wav files need to be handled, and as lseek(2) doesn't
work on pipes aucat can't read .wav files from a pipe.

However, on many simple .wav files the lseek(2) call is a no-op
because there's no header to skip. Furthermore, to skip small headers
and/or padding, read(2) could be used instead of lseek(2), which works
on pipes.

There's a second problem. The .wav file has a header that contains the
data chunk size. Programs generating the .wav file, like faad, don't
know the decoded data size in advance. So, they write the header with
zeroed data size field, then write the data chunk, and finally
lseek(2) to the header to fixup the data size field.

This can't work with pipes because of the lseek(2) call and the files
end up with an invalid header (zero data chunk size). Certain programs
interpret zero as "until the end of the file" (mpv, ffmpeg) and manage
to play such files, other as don't.

The diff in the other mail addresses these two problems.

> Aren't the headers kept in
> the front, and my understanding is maybe you can grab enough bytes
> to check if a header is present. I thought wav is just a raw sample
> with a small header. I'd think a quick check for header wouldn't
> upset playback for raw samples without one.

Yes, this would be nice to have, to avoid using -h

Re: my first patch

[Alexandre Ratchov]

On Wed, Oct 25, 2023 at 12:06:05AM +0600, Maria Morisot wrote:
> 
> I don't have a test machine and I'm trying to keep my installation
> as simple as possible, but if anyone wants to try piping a wav file
> into mplayer or ffplay, I'd be interested in the results. Does it
> work?

faad -o file.wav file.m4a

results in a file.wav that aucat and most players can play.

faad -w file.m4a | cat >file.wav

results in a file with zero-size data chunk (because faad couldn't
seek to the beginning of the file to fixup the header). aucat,
audacious, audacity and sox can't play it; mpv, and ffplay can

Here's a diff for aucat to cope with such files:

  - if the header indicates zero-size data chunk, try to play the data
until the end of the file is reached

  - if there are small sections to skip (padding for alignement or
meta info), then read it instead of using lseek(2)

  - short reads are allowed for pipes, so when reading the headers,
retry if needed.

please test

Index: afile.c
===
RCS file: /cvs/src/usr.bin/aucat/afile.c,v
diff -u -p -r1.12 afile.c
--- afile.c 27 Mar 2023 15:36:18 -  1.12
+++ afile.c 24 Oct 2023 20:05:30 -
@@ -217,14 +217,60 @@ be32_set(be32_t *p, unsigned int v)
 }
 
 static int
+afile_readseg(struct afile *f, void *addr, size_t size)
+{
+   ssize_t n;
+
+   /*
+* retry as pipes may return fewer bytes than requested
+*/
+   while (size > 0) {
+   n = read(f->fd, addr, size);
+   if (n == 0 || n == -1)
+   return 0;
+   addr = (char *)addr + n;
+   size -= n;
+   f->curpos += n;
+   }
+   return 1;
+}
+
+static int
+afile_setpos(struct afile *f, off_t pos)
+{
+   static char unused[512];
+   off_t off = pos - f->curpos;
+
+   /*
+* seek only if needed (to avoid errors with pipes)
+*/
+   if (off != 0) {
+   /*
+* to skip few bytes only (padding, meta-info), simply read
+* them instead of using lseek(2)
+*/
+   if (off > 0 && off <= sizeof(unused)) {
+   log_puts("reading\n");
+   return afile_readseg(f, unused, off);
+   }
+
+   log_puts("seeking\n");
+   if (lseek(f->fd, pos, SEEK_SET) == -1)
+   return 0;
+   f->curpos = pos;
+   }
+   return 1;
+}
+
+static int
 afile_readhdr(struct afile *f, void *addr, size_t size)
 {
-   if (lseek(f->fd, 0, SEEK_SET) == -1) {
+   if (!afile_setpos(f, 0)) {
log_puts(f->path);
log_puts(": failed to seek to beginning of file\n");
return 0;
}
-   if (read(f->fd, addr, size) != size) {
+   if (!afile_readseg(f, addr, size)) {
log_puts(f->path);
log_puts(": failed to read header\n");
return 0;
@@ -301,7 +347,7 @@ afile_wav_readfmt(struct afile *f, unsig
}
if (csize > WAV_FMT_EXT_SIZE)
csize = WAV_FMT_EXT_SIZE;
-   if (read(f->fd, &fmt, csize) != csize) {
+   if (!afile_readseg(f, &fmt, csize)) {
log_puts(f->path);
log_puts(": failed to read format chunk\n");
return 0;
@@ -377,7 +423,7 @@ afile_wav_readhdr(struct afile *f)
log_puts(": missing data chunk\n");
return 0;
}
-   if (read(f->fd, &chunk, sizeof(chunk)) != sizeof(chunk)) {
+   if (!afile_readseg(f, &chunk, sizeof(chunk))) {
log_puts(f->path);
log_puts(": failed to read chunk header\n");
return 0;
@@ -389,7 +435,15 @@ afile_wav_readhdr(struct afile *f)
fmt_done = 1;
} else if (memcmp(chunk.id, wav_id_data, 4) == 0) {
f->startpos = pos + sizeof(riff) + sizeof(chunk);
-   f->endpos = f->startpos + csize;
+   if (csize > 0)
+   f->endpos = f->startpos + csize;
+   else {
+   if (log_level >= 2) {
+   log_puts(f->path);
+   log_puts(": reading to end-fo-file\n");
+   }
+   f->endpos = -1; /* read until EOF */
+   }
break;
} else {
 #ifdef DEBUG
@@ -404,7 +458,7 @@ afile_wav_readhdr(struct afile *f)
 * next chunk
 */
pos += sizeof(struct wav_chunk) + csize;
-   if (lseek(f->fd, sizeof(riff) + pos, SEEK_SET) == -1) {
+   if (!afile_setpos(f, sizeof(riff) + pos)) {
log

Re: my first patch

[Alexandre Ratchov]

On Tue, Oct 24, 2023 at 09:15:57PM +0600, Maria Morisot wrote:
> It is my understanding that wav files contain the headers necessary for a 
> program to adjust the audio settings for play, or to do the software process 
> necessary to reformat the input to the audio device.
> 
> It doesn't make sense to have the wav headers if they aren't going to be 
> used. Tell me if I'm wrong.
> 
> I'm not very good at C but I'm willing to try to fix aucat to adjust wav 
> output in response to the headers if that's something that seems like it's 
> broken.
> 

You're right. The .wav headers require to lseek(2) within the file
which doesn't work on a pipes. It could work on certain files which
headers are placed in a way lseek(2) doesn't need to move the file
pointer.

You could try to modify aucat to skip the lseek(2) calls if it
wouldn't change the file pointer.  Possibly call read(2) and discard
few bytes when the file pointer moves forward by few bytes only (iirc
.wav needs data to be aligned).

HTH

Re: my first patch

[Alexandre Ratchov]

On Tue, Oct 24, 2023 at 05:10:53PM +0600, Lucretia wrote:
> 
> a bit off-topic, but:
> gethsemane$ faad -w Tori_Amos/The_Beekeeper/03* | aucat -i - -h wav
> makes Tori sound like Minnie Mouse. How can I fix this?
> 

you've make faad and aucat use the same data format, ex:

faad -d -f2 -w foobar.m4a | aucat -e s16 -i -

possibly use the -r option if the rate is not 48kHz (which is aucat
default). Alternatively, output in a temporary .wav file and play it
after it's decoded

Re: Audio issue: noise/interference

[Alexandre Ratchov]

On Fri, Jul 07, 2023 at 06:23:26PM -0400, Ricky Cintron wrote:
> I recently resolved an audio issue where I could hear a constant, light
> static noise in my earphones. It wasn't loud or distracting, but it was
> always there. The solution was to remove 'mix' as a source for mix2 and
> mix3.
> 
> However, once I got rid of that static, I noticed some additional noise
> that was apparently hidden behind the original static. Compared to the
> first issue, this noise is quieter and not constant. Anyway, it
> manifests itself in the following ways:
> 
> 1) Very light static noise that never increases, but I've noticed that
> when I load a web page (YouTube, for example), the noise is silenced
> until the page finishes loading. This also sometimes happens when I
> move the mouse cursor around the web browser window, but very briefly.
> It's easier to notice when loading a page since it lasts longer.
> 
> 2) Moving the mouse generates a barely audible buzzing sound, but this
> either doesn't occur or is barely noticeable when moving the cursor on
> a web browser window.
> 
> To troubleshoot, I inspected all the cables in the back of the
> computer (power, DP, ethernet, USB keyboard, USB mouse, speakers/line),
> and unplugged them (except the power cable) one at a time. I didn't
> hear a difference, good or bad. I also turned some mixerctl knobs with
> no noticeable effects.
> 
> Does anyone have any ideas? This isn't a big deal since I can't notice
> it while listening to audio, and it's pretty easy to tune out even
> without audio, but I'd still like to remove it if possible. I'm
> considering buying a USB audio interface, so if that even works, that
> could be a solution.

Check that your AC power plug is connected to the ground. Possibly
plug the computer in another plug, in another room, and see if this
makes any difference.

FWIW, I managed to reduce similar noises by putting ferrite rings on
most cables, the HDMI cable was a significant source of noise in my
case. I didn't try to put ferrite rings on the internal cables
(ex. those between the power supply and the motherboard), but it might
make sense as well.

Certain motherboards are just not well designed and noise might
remain, no matter what you do. A good audio interface would solve this
problem, assuming you're using speakers that don't generate noise or
passive headphones.

HTH

Re: Data source of record.bytes in audioctl

[Alexandre Ratchov]

On Mon, Jul 03, 2023 at 05:18:13PM -0400, Ricky Cintron wrote:
> While troubleshooting some audio issues, I noticed that the values of
> play.bytes and record.bytes in audioctl's output were identical, even
> when only playing audio.
> 
> 1) Is this expected behavior?

yes, by default the device always does DMA in both directions
(synchronously), so record.bytes increases like play.bytes

> 2) What is the source of this data (record.bytes)?
> 

The source is the audio hardware interrupts. The audio(4) driver
handles them and increments its couter. The counter is readable by
userland with the AUDIO_GETPOS ioctl.

> I found it interesting that the values were the same, so I took a look
> at mixerctl, and noticed that 'line' (which is an output) and 'mix'
> (which has line as its only source) were the sources for both
> record.adc variables. At that point I figured that simply removing
> all sources from those two variables would eliminate all audio data
> from those recording channels, but record.bytes continued to match
> play.bytes. I even attempted to mute both ADCs and to disable recording
> in mixerctl (without rebooting), but nothing changed.
> 
> I'm probably going to remove 'line' and 'mix' as sources for the ADCs
> because they don't make sense there, but I'm still hoping to understand
> what's going on.
>

The mixer is a completely different thing and is completely
independent from DMA. It is supposed to control the analog
knobs/selectors, jack sensors, and alike.

Setting the record level to 0 (or removing all sources) would make the
ADC sample silence and produce zeros without affecting how it
works. That's why record.bytes still increases.

> # mixerctl -v
> inputs.dac-2:3=126,126
> inputs.dac-0:1=126,126
> record.adc-0:1_mute=off  [ off on ]
> record.adc-0:1=124,124
> record.adc-2:3_mute=off  [ off on ]
> record.adc-2:3=124,124
> inputs.mix_source=line  { line }
> inputs.mix_line=120,120
> inputs.mix2_source=dac-2:3  { dac-2:3 mix }
> inputs.mix3_source=dac-0:1  { dac-0:1 mix }
> outputs.spkr_source=mix2  [ mix2 ]
> outputs.spkr_mute=on  [ off on ]
> outputs.spkr_eapd=on  [ off on ]
> outputs.line_source=mix3  [ mix2 mix3 ]
> outputs.line_mute=off  [ off on ]
> inputs.line=85,85
> outputs.line_dir=output  [ none output input input-vr0 input-vr50 input-vr80
> input-vr100 ]
> outputs.line_boost=off  [ off on ]
> outputs.line_eapd=on  [ off on ]
> outputs.hp_source=mix2  [ mix2 mix3 ]
> outputs.hp_mute=off  [ off on ]
> outputs.hp_boost=off  [ off on ]
> outputs.hp_eapd=on  [ off on ]
> record.adc-2:3_source=line,mix  { line mix }
> record.adc-0:1_source=line,mix  { line mix }
> outputs.line_sense=plugged  [ unplugged plugged ]
> outputs.hp_sense=unplugged  [ unplugged plugged ]
> outputs.spkr_muters=line,hp  { line hp }
> outputs.master=126,126
> outputs.master.mute=off  [ off on ]
> outputs.master.slaves=dac-2:3,dac-0:1,spkr,line,hp  { dac-2:3 dac-0:1 spkr
> line hp }
> record.volume=124,124
> record.volume.mute=off  [ off on ]
> record.volume.slaves=adc-0:1,adc-2:3  { adc-0:1 adc-2:3 line }
> record.enable=sysctl  [ off on sysctl ]
> 
> 

Re: "ticking" noise when recording audio

[Alexandre Ratchov]

On Fri, Jun 02, 2023 at 11:32:31AM -0700, Courtney wrote:
> It seems when I make any changes to sndiod, the output remains
> the same. I played with -z, -b, -e, -r. Here's the audioctl output.
> Note, the device changed to aucioctl2 but it is still the same
> device in question.
> 
> audioctl -f /dev/audioctl2
> name=uaudio1
> mode=play
^

the device is playing, but according to dmesg from your other mail:

uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls
audio1 at uaudio0

the failing device is record-only. Could verify this. The string after
"name=" in the audioctl output corresponds to the device name in
dmesg.

> pause=0
> active=1
> nblks=16
> blksz=480
> rate=48000
> encoding=s16le
> play.channels=2
> play.bytes=1820160
> play.errors=0
> record.channels=2
> record.bytes=0
> record.errors=0
> 
> I guess the next part then will be to learn to compile the kernel
> with UAUDIO_DEBUG. I suspect you were looking for play or record
> errors in this output.
>

See "Building a Custom Kernel" section in:

https://www.openbsd.org/faq/faq5.html

You only need to add:

option UAUDIO_DEBUG

to the config file (the copy of GENERIC.MP).

Re: "ticking" noise when recording audio

[Alexandre Ratchov]

On Thu, Jun 01, 2023 at 11:35:24AM -0700, Courtney Hicks wrote:
> I hope this reaches you. I think my mail server is having troubles
> communicating with the mailing list. I changed the rate and buffer
> size using aucat, not sndiod, and that changed the rate. I have
> the .wav attached.

The output.wav file is strange, there's a DC offset and

The periodic clicks with smooth edges. Could you post the output of
'audioctl -f /dev/audioctl1' while you're recording?

Re: "ticking" noise when recording audio

[Alexandre Ratchov]

On Thu, Jun 01, 2023 at 11:35:24AM -0700, Courtney Hicks wrote:
> I hope this reaches you. I think my mail server is having troubles
> communicating with the mailing list. I changed the rate and buffer
> size using aucat, not sndiod, and that changed the rate. I have
> the .wav attached. Also of note, I pasted the wrong aucat command
> I ran. It should be
> 
> $ aucat -f snd/1 -o - | aucat -i -
> or
> $ aucat -f snd/1 -o output.wav
> 
> Courtney
> 

To debug this, you really need to change sndiod options. There is
buffering at every software (and hardware) layer and we need to tweak
the uaudio(4) operating mode (I'm suspecting the driver, which is the
only layer whick behavior depends on the hardware in use).

To do so, I'd suggest to stop sndiod(8) and run in on a terminal with
the '-dd' options. This allows to quickly tweak the device modes. Example:

$ doas sndiod -dd -z 256 -f rsnd/1
^C
$ doas sndiod -dd -z 320 -r 16000 -f rsnd/1
^C
...

FWIW, you can see the hardware operating mode by running this command
while the device is recording:

$ doas audioctl -f /dev/audioctl1
name=envy0
mode=play,record
pause=0
active=1
nblks=2
blksz=240
rate=48000
encoding=s24le4msb
play.channels=2
play.bytes=5464320
play.errors=0
record.channels=2
record.bytes=5464320
record.errors=0

Unless this shows what's going on, the next move will be to build a
kernel with UAUDIO_DEBUG and see if there are warnings on the console.

Re: "ticking" noise when recording audio

[Alexandre Ratchov]

- If you change the sndiod(8) rate (-r option), or buffer size (-b
  option) does the ticking change?

- could you send me a short .wav file with the ticking sound?

On Wed, May 31, 2023 at 11:59:20PM -0700, Courtney Hicks wrote:
> Hello all,
> 
> I am trying to record audio from a USB device. I successfully
> get audio from it, however, there is a constant "ticking" sound
> that happens whether or not audio is actually playing through
> the device. Here's the device from the dmesg:
> 
> uvideo0 at uhub0 port 7 configuration 1 interface 0 "MACROSIL AV TO USB2.0"
> rev 2.00/1.21 addr 2
> video0 at uvideo0
> uaudio0 at uhub0 port 7 configuration 1 interface 3 "MACROSIL AV TO USB2.0"
> rev 2.00/1.21 addr 2
> uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls
> audio1 at uaudio0
> 
> I enabled kern.audio.record, have tried aucat and ffmpeg to record
> the audio to file, but they both suffer the same issue. Tried monitoring
> with this command:
> 
> $aucat -f snd/1 -d -r 96000 -o - | aucat -i -
> stdout: rec, chan 0:1, 48000Hz, s24le4msb
> snd/1: 48000Hz, rec 0:1, 18 blocks of 480 frames
> stdout: started
> started
> stdout: stopped
> 
> I can hear the audio I expect but behind the "ticking" noise.
> I'm using this device to get audio/video from a VCR, I can confirm
> it is not the VCR or this device since they both work fine with OBS
> studio on Linux. Any help is much appreciated.
> 
> Courtney
> 
> 

Re: how to transmit desktop sound on xenodm.

[Alexandre Ratchov]

On Mon, Mar 20, 2023 at 10:46:27AM +0100, Omar Polo wrote:
> On 2023/03/19 18:11:29 +, openbsd_send  
> wrote:
> > Dear everyone.
> > I have any Questions for sndiod and pulseaudio.
> > 
> > I tried [OpenBSD Remote] to [Windows Local]...
> > but, I was never to get success...
> > how can i do it...
> > 
> > I am using X11VNC by Xvfb...
> > I want to get Desktop sound...
> > 
> > have any ideas?
> 
> I might be wrong but firefox shouldn't be using pulseaudio on OpenBSD,
> so tunnelling it doesn't do anything.
> 
> I'm also not sure you're doing the sndiod remote audio thingy
> correctly.
> 
> (see )
> 
> You should be running sndiod with the -L- flag on the system where you
> want to audio to be played (i.e. windows in your case -- don't know if
> there is a port of sndio for it or if it could work with the linux
> subsystem) and run
> 
>   $ AUDIODEVICE=snd@192.168.2.10/0 firefox
> 
> on OpenBSD so that the audio is sent thru your lan and being played on
> your Windows machine.
> 
> Unfortunately I don't have the slightest idea whether sndio runs under
> Windows; I've only did something like that with a rpi3 running linux
> and it worked fine :)
> 

I confirm, there's no windows port of libsndio.

Re: sndiod and midicat routing issue.

[Alexandre Ratchov]

On Sun, Jan 15, 2023 at 07:35:49PM +0100, Brian Durant wrote:
> On 1/15/23 12:26, Alexandre Ratchov wrote:
> > On Sun, Jan 15, 2023 at 09:38:38AM +0100, Brian Durant wrote:
> > > The following command will connect a USB MIDI device:
> > > 
> > > $ midicat -d -q midi/0 -q midithru/0 &
> > > 
> > > A second device can be connected as follows:
> > > 
> > > $ midicat -d -q midi/1 -q midithru/1 &
> > > 
> > > Both output MIDI code in the terminal. (Note that redirecting both MIDI
> > > devices to midithru/0 doesn’t seem to pipe both devices through, but 
> > > rather
> > > only midi/0.) Adding the following command provides a way to convert MIDI
> > > code to sound using Fluidsynth:
> > 
> > Redirecting two ports to midithru/0 is supposed to work:
> > 
> > $ midicat -d -q midi/0 -q midithru/0   # in one terminal
> > $ midicat -d -q midi/1 -q midithru/0   # in another terminal
> > 
> > should merge the two inputs. Both terminals should show the events of
> > the corresponding input. If there's a synth on midithru/0
> > (ex. fluidsynth command below is running) it will produice sounds for
> > both inputs.
> 
> Hmm. Seems to be working now. However, this just means that MIDI signals go
> from both MIDI devices to one instance of fluidsynth. This of course means
> that both devices are sending MIDI code to one soundfont instrument. If run
> as:
> 
> $ midicat -d -q midi/0 -q midithru/0
> 
> and
> 
> $ midicat -d -q midi/1 -q midithru/1
> 
> MIDI input could be used to play different soundfont instruments - one for
> midi/0 and one for midi/1. Possibly something with the Fluidsynth "-L"
> option?

IIRC, you need "-p midithru/1" for the second fluidsynth instance.

> The problem is the same for LMMS. However, only one MIDI input is
> ever available. Enabling MIDI input and choosing different channels for SF2
> Player and Kicker do not provide a second MIDI input to choose from when the
> clicking the relevant plugin's gear icon in the "song editor" window. Not
> even when running midicat as I have suggested above. Hopefully this won't
> raise any hackles me writing this, but what I am describing is the normal
> expectation for using MIDI under Windows, Mac and Linux... I realize that
> this is achieved in various ways depending on the OS, but particularly the
> expected use case scenario that I describe for LMMS provides some challenges
> in OpenBSD.

I don't use lmms very often, but I'd recommend you to configure your
keyboards to use different channels (ex. 0 and 1) and route both of
them to midithru/0.

Then, in LMMS, for each track select the appropriate channel: click on
the piano icon, check "enable midi input" and select the desired
channel number (mind lmms counts starting from 1, so it would be 1 and
2 respectively).  This way each plugin will get the input from the
desired keyboard.

AFAIU, LMMS supports only one MIDI input, so you've to use channels if
you need to wire different keyboards to different plugins.

HTH

Re: sndiod and midicat routing issue.

[Alexandre Ratchov]

On Sun, Jan 15, 2023 at 09:38:38AM +0100, Brian Durant wrote:
> The following command will connect a USB MIDI device:
> 
> $ midicat -d -q midi/0 -q midithru/0 &
> 
> A second device can be connected as follows:
> 
> $ midicat -d -q midi/1 -q midithru/1 &
> 
> Both output MIDI code in the terminal. (Note that redirecting both MIDI
> devices to midithru/0 doesn’t seem to pipe both devices through, but rather
> only midi/0.) Adding the following command provides a way to convert MIDI
> code to sound using Fluidsynth:

Redirecting two ports to midithru/0 is supposed to work:

$ midicat -d -q midi/0 -q midithru/0   # in one terminal
$ midicat -d -q midi/1 -q midithru/0   # in another terminal

should merge the two inputs. Both terminals should show the events of
the corresponding input. If there's a synth on midithru/0
(ex. fluidsynth command below is running) it will produice sounds for
both inputs.

> 
> $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2
> 
> However, this only works for midi/0. The same is the case when using LMMS
> with SF2 Player and Kicker. I can get sound with SF2 Player or Kicker, but
> there again appears no way to connect the second device to the second
> plugin. Connecting two MIDI devices (or one device with keys and pads on two
> channels) is not an unusual use case scenario, so I am assuming that there
> is a solution without having to resort to midish.
> 

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Fri, Jan 13, 2023 at 01:10:56PM +0100, Jan Stary wrote:
> > > > I'd certainly be interested in the ability to play audio in a way
> > > > that avoids resampling altogether,
> > > 
> > > If you have a 48kHz file, and your audio device can only do 44100,
> > > then you have to resample, no way around it.
> 
> > > > similar to what a user can do on FreeBSD with the
> > > > following sysctl tweaks:
> > > > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
> 
> > > It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do
> > > if the sample rate (or some other characteristics) is not what the device
> > > itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10
> 
> On Jan 10 09:36:28, a...@caoua.org wrote:
> > chown  /dev/audio*
> > rcctl stop sndiod
> 
> After doing that,
> 
> $ play -V 48000.wav
> play:SoX v14.4.2
> play INFO formats: detected file format type `wav'
> 
> Input File : '48000.wav'
> Channels   : 2
> Sample Rate: 48000
> Precision  : 16-bit
> Duration   : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors
> File Size  : 4.80M
> Bit Rate   : 1.54M
> Sample Encoding: 16-bit Signed Integer PCM
> Endian Type: little
> Reverse Nibbles: no
> Reverse Bits   : no
> 
> 
> Output File: 'default' (sndio)
> Channels   : 2
> Sample Rate: 48000
> Precision  : 16-bit
> Duration   : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors
> Sample Encoding: 16-bit Signed Integer PCM
> Endian Type: little
> Reverse Nibbles: no
> Reverse Bits   : no
> 
> play INFO sox: effects chain: input  48000Hz  2 channels
> play INFO sox: effects chain: output 48000Hz  2 channels
> In:15.4% 00:00:03.84 [00:00:21.16] Out:184kk [---=|=---  ]
> Clip:0
> 
> $ play -V 44100.wav
> play:SoX v14.4.2
> play INFO formats: detected file format type `wav'
> 
> Input File : '44100.wav'
> Channels   : 2
> Sample Rate: 44100
> Precision  : 16-bit
> Duration   : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors
> File Size  : 4.41M
> Bit Rate   : 1.41M
> Sample Encoding: 16-bit Signed Integer PCM
> Endian Type: little
> Reverse Nibbles: no
> Reverse Bits   : no
> 
> Output File: 'default' (sndio)
> Channels   : 2
> Sample Rate: 44100
> Precision  : 16-bit
> Duration   : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors
> Sample Encoding: 16-bit Signed Integer PCM
> Endian Type: little
> Reverse Nibbles: no
> Reverse Bits   : no
> 
> play INFO sox: effects chain: input  44100Hz  2 channels
> play INFO sox: effects chain: output 44100Hz  2 channels
> In:25.3% 00:00:06.32 [00:00:18.68] Out:279kk [ =|= ]  Clip:0
> Aborted.
> 
> $ aucat -i 44100.wav
> default: unsupported audio params
> 
> $ aucat -i 48000.wav
> default: unsupported audio params
> 
> 
> It seems sox negotiates either 48000 or 44100 with sndio
> (meaning the sndio library, not the non-running sndiod) and sends that,
> but aucat errors out. But the device itself can do 48000 (says audioctl),
> so is that a bug in aucat?
> 

It's not related to the sample rate. Internally aucat uses 24-bit
samples lsb-aligned in 32-bit words. Then, it assumes the device
supports everything and doesn't bother setting up a conversion layer.

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Wed, Jan 11, 2023 at 02:43:25PM +0100, Jan Stary wrote:
> On Jan 11 01:10:11, a...@caoua.org wrote:
> > On Tue, Jan 10, 2023 at 08:22:27PM +, John Rigg wrote:
> > > 
> > > > > # If I recall correctly, I converted to FLAC here because the WAV 
> > > > > headers
> > > > > # generated by aucat and SoX differed, and so SoX would refuse to 
> > > > > play WAV fil
> > > > es
> > > > > # created by aucat.
> > > > 
> > > > That would be a bug in itself.
> > > > How exactly does SoX refuse to play the WAVs created by aucat?
> > > 
> > > sox is strict about headers and will complain if cbSize is inconsistent 
> > > with
> > > fmt size. Workaround is to use the '-t sndfile' option.
> > > 
> > > aucat is not alone here; several other programs write .wav files that
> > > require this option with sox.
> > > 
> > 
> > Here's a diff to switch aucat to extended wav format. According to
> > Microsoft docs, it is needed if bits > 16 or if there are more than 2
> > channels, which aucat supports. It fixes the sox problem.
> 
> Thank you.
> 
> One nit that's perhaps related: $ aucat -n in.wav -o out.wav
> produces a stereo 24bit out.wav, as -c 0:1 -e s24 is the default.
> Would it make more sense with -n to preserve the characteristics
> of in.wav instead?
> 

Yes, this is on my todo list, including preserving the sample rate,
which is the most annoying.

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Tue, Jan 10, 2023 at 08:22:27PM +, John Rigg wrote:
> 
> > > # If I recall correctly, I converted to FLAC here because the WAV headers
> > > # generated by aucat and SoX differed, and so SoX would refuse to play 
> > > WAV fil
> > es
> > > # created by aucat.
> > 
> > That would be a bug in itself.
> > How exactly does SoX refuse to play the WAVs created by aucat?
> 
> sox is strict about headers and will complain if cbSize is inconsistent with
> fmt size. Workaround is to use the '-t sndfile' option.
> 
> aucat is not alone here; several other programs write .wav files that
> require this option with sox.
> 

Here's a diff to switch aucat to extended wav format. According to
Microsoft docs, it is needed if bits > 16 or if there are more than 2
channels, which aucat supports. It fixes the sox problem.

No regressions found with various ports and few windows programs.

ok?

Index: afile.c
===
RCS file: /cvs/src/usr.bin/aucat/afile.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 afile.c
--- afile.c 24 Oct 2021 21:24:15 -  1.9
+++ afile.c 10 Jan 2023 23:52:47 -
@@ -432,12 +432,17 @@ afile_wav_writehdr(struct afile *f)
le32_set(&hdr.riff.size, f->endpos - sizeof(hdr.riff));
memcpy(hdr.fmt_hdr.id, wav_id_fmt, 4);
le32_set(&hdr.fmt_hdr.size, sizeof(hdr.fmt));
-   le16_set(&hdr.fmt.fmt, 1);
+   le16_set(&hdr.fmt.fmt, WAV_FMT_EXT);
le16_set(&hdr.fmt.nch, f->nch);
le32_set(&hdr.fmt.rate, f->rate);
le32_set(&hdr.fmt.byterate, f->rate * f->par.bps * f->nch);
le16_set(&hdr.fmt.blkalign, f->par.bps * f->nch);
le16_set(&hdr.fmt.bits, f->par.bits);
+   le16_set(&hdr.fmt.extsize,
+   WAV_FMT_EXT_SIZE - WAV_FMT_SIZE - sizeof(hdr.fmt.extsize));
+   le16_set(&hdr.fmt.valbits, f->par.bits);
+   le16_set(&hdr.fmt.extfmt, 1);
+   memcpy(&hdr.fmt.guid, wav_guid, sizeof(hdr.fmt.guid));
memcpy(hdr.data_hdr.id, wav_id_data, 4);
le32_set(&hdr.data_hdr.size, f->endpos - f->startpos);
return afile_writehdr(f, &hdr, sizeof(struct wav_hdr));

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Tue, Jan 10, 2023 at 09:11:13AM +0100, Jan Stary wrote:
> I don't get the point of your message explaning what dither is.
> My whole point was that one of the sources of the perceived
> difference between how sox resamples and hows aucat resamples
> might be dithering, as aucat does not differ (right?).
> 

You're right, aucat doesn't dither and quantization noise is audible
for quiet inputs (including when resampling is not involved at all).

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Mon, Jan 09, 2023 at 01:10:09PM -0700, Ashlen wrote:
> 
> Although I need to finalize the Perl script I was using to do this (life gets
> busy), in practice I was able to distinguish between samples created by
> audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon
> with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> array containing the givens A and B to get an unknown X; comparing 15 seconds 
> of
> audio; audio/sox as the playback software. In the future, I would do >=16
> trials, and perhaps conduct the tests from my desktop instead since it has a
> discrete amp and DAC.
> 
> In offline resampling from 48kHz to 44.1kHz, the highs were most affected and
> that's what I was able to use to distinguish between samples. The percussion,
> especially the cymbals, sounded different in particular because the clip
> resampled by aucat had cymbal crashes that seemed to 'shimmer' much less (the
> decay was more rapid). The spectrograms seemed to confirm that the highs were
> most affected. 
> 
> Whether that means "low quality resampling" or merely that the results of the
> two commands can be differentiated is something I'm uncertain of. Either way, 
> I
> don't know enough about C or sndio internals to be useful in that domain yet. 
> As
> an aside, I did find this to be a useful resource for learning about digital
> audio resampling, and they recommend audio/sox there.
> 
> https://ccrma.stanford.edu/~jos/resample/
> 
> I hadn't said anything about this earlier because I wanted to take the time to
> finish + document the script, reproduce my results with a royalty free sample 
> at
> a greater trial count, and then post. Given that I haven't done so yet, I can 
> at
> least post the commands used to resample the audio for those that are
> interested.
> 
> 
> # This was originally an opus file downloaded with www/yt-dlp.
> # Converting to WAV so both SoX and aucat can work with it.
> $ opusdec input.{opus,wav}
> 
> # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> #
> # If I recall correctly, I converted to FLAC here because the WAV headers
> # generated by aucat and SoX differed, and so SoX would refuse to play WAV 
> files
> # created by aucat.
> $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o output-aucat.flac
> 
> # Generate spectrograms for later inspection/comparison.
> $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> $ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png
> 

Thank you for all the details. Do you mind sharing the youtube link
(or the input.wav file) so I can experiment with the same file and
examine the data

> 
> I'd certainly be interested in the ability to play audio in a way that avoids
> resampling altogether, similar to what a user can do on FreeBSD with the
> following sysctl tweaks:
> 
> # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
> 

This is equivalent to bypassing sndiod. The OpenBSD equivalent is as
follows:

chown  /dev/audio*
rcctl stop sndiod

Note that bit-perfect audio and avoiding resampling are not the same
thing. The latter is more complicated but it would keep current
features working (mixing, routing, device switching) by making sndiod
dynamically set device sample rates to match the sample rate of a
particular client (for instance an audio player), other programs (if
any) would resample.

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Sun, Jan 08, 2023 at 10:56:31PM +0100, Jan Stary wrote:
> On Oct 16 08:18:17, a...@caoua.org wrote:
> > On Sat, Oct 15, 2022 at 10:03:52PM +0200, Åke Nordin wrote:
> > > On 10/14/22 11:21, Alexandre Ratchov wrote:
> > > > Here are the measures of the aliasing noise using sine sweeps. Check
> > > > the figure for the 44.1kHz to 48kH conversion, the sndiod column:
> > > > 
> > > > https://arverb.com/pub/src/
> 
> 
> aucat(1) currently says
> 
>   BUGS
>Resampling is low quality.
> 
> Is this still considered to be the case?
> 

IMO, it doesn't deserve the BUGS section anymore, I'll remove this
sentence. Objections?

Re: OpenBSD 7.2 amd64, MIDI error "midi/0: couldn't open port".

[Alexandre Ratchov]

On Fri, Jan 06, 2023 at 10:18:37AM +0100, Brian Durant wrote:
> Hi,
> Completely lost as to the cause for the error. I have read the relevant man
> pages as well as searching the mail archive.
> 
> System info:
> OpenBSD 7.2 amd64, GNOME 42.5, Huawei MateStation S with AMD Ryzen 5 4600G
> and Radeon Graphics.
> 
> Error messages:
> $ midicat -d -q midi/0 -q midithru/0
> midi/0: couldn't open port
> $ midicat -d -q midi/1 -q midithru/0
> midi/1: couldn't open port
> 

according to your dmesg (other mail), you don't any MIDI ports on your
machine.

> Relevant output:
> $ dmesg ...
> uaudio0: sync play xfer, err = 6
> uaudio0: sync play xfer, err = 6
> uaudio0: sync play xfer, err = 6
> ugen2 at uhub2 port 2 "Roland A-PRO" rev 1.10/1.20 addr 3
> 

Do you know if this is class-compliant (aka "driverless")? OpenBSD
supports only class-compliant MIDI devices.

Not all old devices are class-compliant because in the 2000's, Windows
used to have a bug that hardware designers tried to
workaround. Certain devices from the 2000's have a switch (or
configuration parameter) to switch between vendor-specific and
class-compliant modes. Try to dig in the manual. If you can't switch
the device to class-compliant mode, get a USB-MIDI interface, they are
cheap nowadays and just work.

> $ cat /etc/rc.conf.local
> pkg_scripts=avahi_daemon messagebus gdm cups_browsed
> sndiod_flags=-z 128 -f rsnd/1
> 
> $ cat /etc/sysctl.conf
> kern.audio.record=1
> 
> sndiod flags are for reduced latency and for audio to work properly on my
> Huawei MateStation.

seems correct

Re: OpenBSD 7.2 amd64, MIDI error "midi/0: couldn't open port".

[Alexandre Ratchov]

On Fri, Jan 06, 2023 at 10:18:37AM +0100, Brian Durant wrote:
> Hi,
> Completely lost as to the cause for the error. I have read the relevant man
> pages as well as searching the mail archive.
> 
> System info:
> OpenBSD 7.2 amd64, GNOME 42.5, Huawei MateStation S with AMD Ryzen 5 4600G
> and Radeon Graphics.
> 
> Error messages:
> $ midicat -d -q midi/0 -q midithru/0
> midi/0: couldn't open port
> $ midicat -d -q midi/1 -q midithru/0
> midi/1: couldn't open port
> 

could you post the output of dmesg (at least the midi-related lines).

> Relevant output:
> $ dmesg ...
> uaudio0: sync play xfer, err = 6
> uaudio0: sync play xfer, err = 6
> uaudio0: sync play xfer, err = 6
> ugen2 at uhub2 port 2 "Roland A-PRO" rev 1.10/1.20 addr 3
> 
> $ cat /etc/rc.conf.local
> pkg_scripts=avahi_daemon messagebus gdm cups_browsed
> sndiod_flags=-z 128 -f rsnd/1
> 
> $ cat /etc/sysctl.conf
> kern.audio.record=1
> 
> sndiod flags are for reduced latency and for audio to work properly on my
> Huawei MateStation.
> 
> Brian
> 
> 

Re: Crackling in sndio

[Alexandre Ratchov]

On Fri, Dec 09, 2022 at 01:41:55PM +0300, Aleksandr Mikhaylov wrote:
> Hello all!
> 
> I'm using OpenBSD 7.2 RELEASE, 
> but I've seen this problem on earlier versions as well. 
> Please tell me, when I am playing audio through sndio,
> for example with firefox or mpd, 
> and the processor load starts to increase,
> for example because I opened a heavy web page or some heavy application,
> sometimes I hear clicks, or my audio is interrupted,
> and I have to restart the playback.
> I can see in the mpd log at this time:
> 
> output: Failed to play on "Libao Audio Device" (sndio): sndio write failed
> 
> I tried increasing the sndiod buffer to 9600,
> but that didn't do anything.
> I also tried running sndio with the -d flag,
> but I didn't see any errors. 
> I have two laptops with OpenBSD, a Thinkpad x250 and a Latitude 5300,
> and both laptops have this problem.
> If anyone can tell me what might be the problem,
> I would be very grateful, thank you very much.

I've noticed similar problems and many have reported them. The OpenBSD
kernel is not preemptive, so while big programs (including browsers)
are running long kernel code-paths, audio doesn't get the CPU timely
and audio drops.

AFAICS, the kernel is improving a lot with time, but browsers (and
sites they are running) are becoming heavier, compilers are becoming
heavier, etc.

Interestingly (at least to my ears and for my workload) the annoyances
caused by big programs don't depend much on the audio deadline (at
least in the 10-100ms range). This suggests that there are only huge
non-preemptive kernel code-paths. Userland is affected, USB audio
devices (operated at IPL_SOFTNET) are affected, but PCI devices
(operated at IPL_AUDIO) are not affected; this might indicate that the
blocking code paths run at above IPL_SOFTNET and below IPL_AUDIO. My 2
cents, in case this rings a bell to someone.

Meanwhile, I suggest you to try to reduce the processes/services that
you dont need but load the kernel. In my experiences processes that
allocate/free big amounts of memory always cause underruns.

HTH

Re: Connect MIDI keyboard to SF2 player in LMMS - OpenBSD 7.2.

[Alexandre Ratchov]

On Tue, Nov 08, 2022 at 11:31:24AM +0100, Brian Durant wrote:
> I am trying to connect my MIDI keyboard to the Sf2 Player, in LMMS. sndio
> MIDI is set under MIDI interface in the MIDI settings section of the LMMS
> preferences. DMESG gives me the following when I plug my MIDI keyboard into
> the computer:
> 
> umidi0 at uhub0 port 5 configuration 1 interface 0 "KORG INC. microKEY2" rev
> 1.10/1.02 addr 3
> umidi0: (genuine USB-MIDI)
> umidi0: out=1, in=1
> midi0 at umidi0: 
> 
> I have read the three bits of LMMS documentation on MIDI, and I am familiar
> with how to use fluidsynth to connect directly with my MIDI keyboard to the
> default soundfont:
> 
> $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2
> $ midicat -d -q midi/0 -q midithru/0
> 
> Unfortunately, none of this seems to work in LMMS. Clicking on the action
> gear for the Sf2 Player plugin shows MIDI input and output, but does not
> list my MIDI keyboard (as in Linux or Windows) so that I can bind it to the
> Sf2 Player. There is very little information about using MIDI instruments in
> the OpenBSD FAQ, and my knowledge of sdiod and jack are limited.

Basically, sndio MIDI attempts to look as MIDI hardware.

The computer's MIDI ports are named "midi/0", "midi/1", .. and (in the
default sndiod config) they correspond the "midi0 at ..." lines of
dmesg.

There are also software MIDI thru boxes refered as "midithru/0",
"midithru/1", ... For instance, when a program sends events to
"midithru/0" all other programs connected to "midithru/0" receive the
events.

By default programs use "midithru/0" as MIDI port.

Certain have no MIDI port selector, but the default port may be
changed with the MIDIDEVICE environment variable.

> The only way that I have found that I can get this to work, is if I run $
> midicat -d -q midi/0 -q midithru/0 from the command line, before I open LMMS
> and I then select MIDI input in the Sf2 Player action gear. However, this
> allows only for one MIDI instrument at a time. If I also want to connect a
> drumpad like the Akai MPK 218, would I run $ midicat -d -q midi/1 -q
> midithru/1 and how do I set MIDI input in the Kicker plugin to only get the
> MIDI signals from the drumpad and not the keyboard? Perhaps LMMS and sndio
> are only setup for something like the Akai MPK Mini MKIII?
> 
> Any help trying to wrap my head around how MIDI, sndio and jack work in this
> context is appreciated.
> 

If you've multiple MIDI controllers, you could assign a MIDI channel
to each (most MIDI controllers have a knob to do so) and then route
them all to "midithru/0" so lmms or fluidsynth see them as a single
port. For instance:

midicat -d -q midi/0 -q midithru/0
midicat -d -q midi/1 -q midithru/0

Then, in lmms (or fluidsynth), configure each track's "Input channel"
setting to the corresponding input (click on the "keyboard" icon, then
the "enable midi input" button, then select the channel number).  If
you need a more complex MIDI routing, you could try the audio/midish
port.

Note that certain programs count channel numbers from 0 other from 1.

You may need to set sndiod latency (ex. "-z 128" option) and lmms
buffer size (Edit->Settings set buffer size to 128).

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Fri, Oct 14, 2022 at 04:01:45PM -0400, Geoff Steckel wrote:
> > 
> > I did simple A/B tests with music from CDs and my ears couldn't hear
> > the aliasing noise. Try it.
> Good a/b >x< tests for audio require extreme care to get accurate results.
> Simple sine sweeps don't show IM distortion well.
> In most cases numerically equal amounts of IM distortion are far more easily
> noticed than harmonic distortions or simple noise (white, pink, etc.)

Sure, there is measurable aliasing. My questioning is: is it audible
in 99% of the cases?

Remains the question, how to handle the 1% remaining. For now,
resampling off-line is the least annoying, IMHO.

> > Sometimes you just don't want to think about it (ex., when you debug
> > audio stuff), so resampling off-line (or switching the device rate)
> > still makes sense in certain cases.
> This is the classic "why would you ever want to do that?"
> "Just as good" is an opinion.
> Other OSs can and do provide controls which allow setting the device
> sample rate to whatever the device can do.
> This user wants that to work.
> 
> This means compiling a kernel with AUDIO_DEBUG Real Soon Now
> and inserting a few more DPRINTFs.

AFAIK, sample rate changes in the kernel are OK, at least in uaudio
driver.

Now it's all in sndiod (or how to bypass sndiod to get bit-perfect
audio)

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Sat, Oct 15, 2022 at 10:03:52PM +0200, Åke Nordin wrote:
> On 10/14/22 11:21, Alexandre Ratchov wrote:
> > Here are the measures of the aliasing noise using sine sweeps. Check
> > the figure for the 44.1kHz to 48kH conversion, the sndiod column:
> > 
> > https://arverb.com/pub/src/
> 
> Those are interesting results, indeed. Is there a write-up about the
> testing method somewhere where I can read how to reproduce such tests?
> 

Sorry, no detailed write-up, but I did the aliasing measurement
roughly as follows. Example for 44.1kHz to 48kHz:

First generate a sine sweep at 44.1kHz, up to half the sample rate:

sox -V -r 44100 -n sweep-44100.aif synth 30 sin 0+22050 gain -6

the gain must be slightly reduced to avoid filter over-shoots which
would clip and show the clipping distortion. Then, resample the file
to 48kHz using aucat (it uses the same algorithm as sndiod):

aucat -n -i sweep-44100.aif -r 48000 -c 0:0 -o sweep-44100-48000.aif

And plot the spectrogram:

sox sweep-44100-48000.aif -n spectrogram -o sweep-44100-48000.png

sxiv sweep-44100-48000.png

The column with the "linear" method is obtained by resampling using
the old aucat version. The column with the "offline" method is
obtained by resampling with sox instead of aucat.

Let me know if you need more information or have suggestions.

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Fri, Oct 14, 2022 at 06:43:46PM +0200, Jan Stary wrote:
> > > In my experience resampling quality in any particular implementation
> > > is not guaranteed and can introduce significant artifacts.
> > > Declaring a particular implementation "good enough" without
> > > knowing more seems premature.
> > 
> > Here are the measures of the aliasing noise using sine sweeps. Check
> > the figure for the 44.1kHz to 48kH conversion, the sndiod column:
> > 
> > https://arverb.com/pub/src/
> > 
> > I did simple A/B tests with music from CDs and my ears couldn't hear
> > the aliasing noise. Try it.
> 
> Does this bit of sndiod(8) still apply?
> 
>   BUGS
>Resampling is low quality; down-sampling especially
>should be avoided when recording.
> 

AFAICS, aliasing is not audible in most desktop setups.  People with
pro equipment probably already avoid real-time resampling.

So, if nobody objects, I'll drop it.

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Thu, Oct 13, 2022 at 05:20:49PM -0400, Geoff Steckel wrote:
> 
> If those don't work it's a (fixable) bug/not-yet-implemented.
> I've tried those settings with ambiguous results but not failure.
> My usb dacs don't have visible indicators & I don't have a
> USB protocol sniffer.

Running audioctl during playback reveals the device sample rate.

> In my experience resampling quality in any particular implementation
> is not guaranteed and can introduce significant artifacts.
> Declaring a particular implementation "good enough" without
> knowing more seems premature.

Here are the measures of the aliasing noise using sine sweeps. Check
the figure for the 44.1kHz to 48kH conversion, the sndiod column:

https://arverb.com/pub/src/

I did simple A/B tests with music from CDs and my ears couldn't hear
the aliasing noise. Try it.

Sometimes you just don't want to think about it (ex., when you debug
audio stuff), so resampling off-line (or switching the device rate)
still makes sense in certain cases.

Re: sndio and bit perfect playback

[Alexandre Ratchov]

On Thu, Oct 13, 2022 at 03:11:50AM +, s...@skolma.com wrote:
> 
> 
> in summary, audio works.. just not bit-perfectly :)
> does anyone know if SNDIO supports such mode ? and how i might configure it.
> 

bit-perfect is practical for one thing only: avoid questionings about
whether the processing adds audible noise & distortion. I've tryed
various hacks, including bypassing sndiod and neither was very
practical.

IMHO, the sndiod resampler covers 99% of the cases. To handle the
remaining 1%, I just resample the files off-line. audio/sox is
excellent for that.

So, I'd suggest you to add "-e s24" to sndiod_flags and resample
off-line when needed.

HTH

Re: xine's ffmpegaudio doesn't downmix, sio_getpar() reports 6 channels instead of 2

[Alexandre Ratchov]

On Mon, Oct 03, 2022 at 07:45:19PM +0200, Marc Espie wrote:
> > 
> > This is a known problem. While mpv and mplayer have options to turn
> > the downmixing, it's not OK this to be manual.
> ???
> 
> Cannot parse.
> If you cannot write this in english, please say what's going on in french.

- the problem is known (playing a 5.1 track on stereo headphones
  sounds weird)

- mpv and mplayer have and workaround for it: an option to
  turn on downmixing

- having to turn on downmixing manually in every single
  program is not OK

In other words, with the OpenBSD defaults, if you play a movie with a
5.1 audio stream, audio should be acceptable on headphones without
manual tweaks.

HTH

> 
> I couldn't care less about "real time" mixing. I really want surround sound
> on video...

This thread was about downmixing surround to stereo.

But, assuming you've the 5.1-capable audio interface (and all the
speakers), what happens when you do:

rcctl set sndiod flags -c0:5
rcctl restart sndiod

then:

mpv /path/movie_with_5.1_audio.mp4

You should get surround audio. If certain speakers don't work, send me
your dmesg and the output of audioctl during playback

Re: xine's ffmpegaudio doesn't downmix, sio_getpar() reports 6 channels instead of 2

[Alexandre Ratchov]

On Thu, Sep 22, 2022 at 04:31:58PM +, adr wrote:
> Hi,
> 
> first of all, I've never contributed to the xine project, and
> I don't have any experience with sndio, so bear with me...
> 
> Frustrated with the bad sound playing a 6 channels aac audio I decided to
> take a look.  The device is a usb one:
> 
> $ dmesg | grep -i audio
> uaudio0 at uhub2 port 3 configuration 1 interface 1 "GeneralPlus USB Audio 
> Device" rev 1.10/1.00 addr 6
> uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 8 ctls
> audio0 at uaudio0
> uhidev2 at uhub2 port 3 configuration 1 interface 3 "GeneralPlus USB Audio 
> Device" rev 1.10/1.00 addr 6
> 
> It has only 2 channels for playback.
> 
> The file has 5.1 aac audio:
> $ ffprobe file.mp4
> [...]
> Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 
> 224 kb/s (default)
> [...]
> 
> Xine's ffmpegaudio plugin is supposed to do downmix (please, correct
> me if I'm wrong), but:
> 
> $ xine --verbose=2 file.mp4
> [...]
> audio_out: ao_open (0x585415540)
> audio_sndio_out: ao_sndio_open bits=16 rate=48000, mode=128
> audio_sndio_out: ao_sndio_open 6 channels output
> [...]
> 
> The code in xine-lib-1.2.12/src/audio_out/audio_sndio_out.c by Brad
> Smith is following the recommendations at sio_open(3), there is no
> problem there.
> 
> sio_getpar() is returning 6 channels as valid, so the sound ends
> messed up. The right speaker gets mostly ambient sound and the
> voices are almost only audible through the left speaker.
> 
> mplayer and mpv have means to force downmix, but xine is the only
> media player which can play 1080p h264 video with a decent performance
> (if the bitrate is not too high) on an rpi4 (no hardware acceleration,
> cpu at 2.2Gz)
> 
> One workaround for this particular case could be adding the
> configuration setting "audio.output.speaker_arrangement" to
> audio_sndio_out.c.
> 
> I'm using the last snapshot:
> 
> $ doas sysupgrade -ns
> Fetching from https://ftp.OpenBSD.org/pub/OpenBSD/snapshots/arm64/
> SHA256.sig   100% ||  1544
> 00:00 Signature Verified
> Already on latest snapshot.
> 
> base72.tgz21-Sep-2022 11:41   262659517
> 
> Is this behaviour normal and I'm just missing something?
> Some thoughts?

Hi,

This is a known problem. While mpv and mplayer have options to turn
the downmixing, it's not OK this to be manual.

IMHO, the most appropriate (and probably simplest) is to extend sndiod
to do the surround conversions, so the problem would be solved at
system level and all players would benefit (as we do for all other
conversions, btw). Less code, less bugs.

Furthermore, neither the audio subsystem, nor the program can guess
which speakers are plugged (and powered) or how they are placed. So
there will be a knob for this. Better to have a system-level knob than
to have to configure every program.

Re: smtpd with dkim & mailing lists

[Alexandre Ratchov]

On Tue, Aug 30, 2022 at 09:17:44PM +0200, Tobias Fiebig wrote:
> Heho,
>
> The important part is not 'not adding an additional signature' but
> 'not breaking the previous signature'. As long as you do not fiddle
> with anything in there, things will be fine; But, as you most likely
> do (think: Adding a prefix for the subject like [LISTNAME]), DKIM
> will be an issue (mostly, if there is DMARC in play as well).
>

Thank you. I'm using the mlmmj port to manage the lists. By default it
doesn't modify the headers or the body so the DKIM signature is still
valid.

Re: smtpd with dkim & mailing lists

[Alexandre Ratchov]

On Tue, Aug 30, 2022 at 07:26:11PM +0200, Martijn van Duren wrote:
> On Tue, 2022-08-30 at 17:13 +0200, Alexandre Ratchov wrote:
> > Hi,
> > 
> > For my $DAYJOB I had to please big mail corporations and configured
> > smtpd(8) to send DKIM-signed emails (also added SPF and DMARC
> > records). This was easy using instruction in the
> > opensmtpd-filter-dksim port and works fine to send messages to
> > bigmailcorp accounts.
> > 
> > The mail server is used to manage few mailing lists using mlmmj. At
> > first glance, things appear to work:
> > 
> > - The envelope address (aka smtp "mail from:" address or retrun-path)
> >   matches the mailing list server domain (not sender address domain),
> >   which has the proper SPF record.
> 
> This should be fine, although for DMARC to be correct the "MAIL FROM:"
> and From-header should be in line, or else DMARC fails. So mailing
> lists will fail, unless you rewrite the from-header as well.

This is the part I'm unsure, I've found contradictory claims on the
internet.

I've found no such requirement in the RFC (see refs below) and the two
major bigmailcorps I've tested just work (say "dmarc=pass" in header
and/or user interface).

But I found many claims that the "MAIL FROM:" domain is required to
match the From-header domain. Maybe this requirement is only for list
servers that modify the original mail (to add a footer, drop
attachments, tweak headers, etc), which invalidates the orinal sender
DKIM signature. In turn a new DKIM signature is needed but as the list
server can only sign with its own domain, a new From-header with the
list server domain is needed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

refs & reasoning:

The rfc7489, sec. 6.6.2 [*] says the receiver does 3 things: (1) DKIM
signatures checks, (2) SPF checks and (3) "Identifier Alignement"
checks.  The later is defined as:

"If one or more of the Authenticated Identifiers align with the
RFC5322.From domain, the message is considered to pass the
DMARC mechanism check.  All other conditions (authentication
failures, identifier mismatches) are considered to be DMARC
mechanism check failures."

where "Identifier Alignment" is defined in sec. 3 as:

Identifier Alignment: When the domain in the RFC5322.From
address matches a domain validated by SPF or DKIM (or both),
it has Identifier Alignment.

In other words:
 - sender IP must belong to HELO & MAIL FROM (to pass SPF)
 - DKIM signatures must be valid (to pass DKIM)
 - From-header must match the signature or the envelope (to pass DMARC)

Consequently, a "bounced" email should pass DMARC provided that the
mail body and signed headers are preserved. Indeed:
 - IP of the relay would match the new envelope domain SPF record
 - body & header are preserved, so original DKIM signature is valid
 - From-header still matches the DKIM sign. so DMARC passes.

[*] https://www.rfc-editor.org/rfc/rfc7489.html#section-6.6

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> > 
> > - Is there a way to make smtpd(8) add the DKIM signature only if the
> >   sender domain is the local domain? (this would avoid the extra
> >   irrelevant DKIM signature).
> 
> filter-dkimsign is complex enough as it is. I don't really want to add
> too much more complexity. But if you make a strong enough case I'll
> certainly consider it.

please don't, simpler is better ;-)

smtpd with dkim & mailing lists

[Alexandre Ratchov]

Hi,

For my $DAYJOB I had to please big mail corporations and configured
smtpd(8) to send DKIM-signed emails (also added SPF and DMARC
records). This was easy using instruction in the
opensmtpd-filter-dksim port and works fine to send messages to
bigmailcorp accounts.

The mail server is used to manage few mailing lists using mlmmj. At
first glance, things appear to work:

- The envelope address (aka smtp "mail from:" address or retrun-path)
  matches the mailing list server domain (not sender address domain),
  which has the proper SPF record.

- The list server (mlmmj port) resends the without modifying the
  DKIM-signed headers and the DKSIM-Signature header. So the signature
  remains valid. In other words the receiver can verify that the mail
  originated from the sender domain servers even it it's received from
  the list server.

- The list server adds its own signature which is also valid. But
  AFAIU, it's irrelevant as the signing key is not the sender domain
  key.

With all this, mails between gmail and microsoft seem fly through the
lists server.

If the sender domain add a DKIM signature, I guess the mail will be
possibly tagged as spam by bigmailcorps. But it would also be tagged
as spam if the sender did directly send to mailing list members. So,
garbage in, garbage out, no problem.

Certain lists I'm subscribed to seem to use the same approach, others
seem to discard DKIM-Signature headers.

- Is the reasoning correct? Am I missing something?

- Is there a way to make smtpd(8) add the DKIM signature only if the
  sender domain is the local domain? (this would avoid the extra
  irrelevant DKIM signature).

Thanks

Re: USB mic no audio

[Alexandre Ratchov]

On Tue, Aug 16, 2022 at 05:44:29PM -0700, Courtney wrote:
> 
> $ sndiod -dd -f rsnd/2
...
> snd0: 48000Hz, s24le3, play 0:1, rec 0:0, 16 blocks of 480 frames
> snd0: device started

This appears to be a play-only device, so recording can't work,
probably USB attach order has changed. I'd suggest starting with
sndiod defaults (it configures first four devices) and using the
"sndioctl server.device" control to switch to the device with
recording capability (depend on device attach order).

Note that record-only and play-only devices can't be combined and used
as a single full-duplex device yet (see mailing list archives for more
details and workarounds).

Re: Firefox and stuttering USB audio

[Alexandre Ratchov]

On Sat, Jul 30, 2022 at 02:39:08PM -0700, Courtney wrote:
> I hope it isn't in bad etiquette to resurrect an old piece of mail.
> 

OK for me, your mail is attached to the thread.

> Since May I mitigated the stuttering audio issue with Firefox running
> by using Firefox ESR 91. Clearly something beyond 91 added something
> that doesn't jive well with OpenBSD. Now that 91 ESR is gone and it is 102
> the issue has returned.
> 
> I have been playing around with a different issue, but in the process
> of messing with that issue I came across something. I ran sndiod in
> debug mode with these flags:
> 
> sndiod -dd -f rsnd/0 -F rsnd/1
> 
> I then went to try out opening tabs in firefox which then triggered
> a whole bunch of this getting spat out
> 
> snd1: rec hw xrun, rused = 1440/7680
> snd1: play hw xrun, pused = 6240/7680
> snd1: rec hw xrun, rused = 960/7680
> snd1: play hw xrun, pused = 6720/7680
> snd1: rec hw xrun, rused = 480/7680
> snd1: play hw xrun, pused = 7200/7680
> snd1: rec hw xrun, rused = 960/7680
> snd1: play hw xrun, pused = 6720/7680
> snd1: rec hw xrun, rused = 480/7680
> snd1: play hw xrun, pused = 7200/7680
> snd1: rec hw xrun, rused = 1440/7680
> snd1: play hw xrun, pused = 6240/7680
> snd1: rec hw xrun, rused = 960/7680
> snd1: play hw xrun, pused = 6720/7680
> snd1: rec hw xrun, rused = 480/7680
> snd1: play hw xrun, pused = 7200/7680
> snd1: rec hw xrun, rused = 960/7680
> snd1: play hw xrun, pused = 6720/7680
> snd1: rec hw xrun, rused = 480/7680
> snd1: play hw xrun, pused = 7200/7680
> snd1: rec hw xrun, rused = 1440/7680
> snd1: play hw xrun, pused = 6240/7680
> snd1: rec hw xrun, rused = 960/7680
> snd1: play hw xrun, pused = 6720/7680
> snd1: rec hw xrun, rused = 480/7680
> snd1: play hw xrun, pused = 7200/7680
> snd1: rec hw xrun, rused = 960/7680
> snd1: play hw xrun, pused = 6720/7680
> snd1: rec hw xrun, rused = 480/7680
> snd1: play hw xrun, pused = 7200/7680
> 
> I'm wondering if someone has more of a clue as to what all
> this means.

This confirms that sndiod woke up too late, probably because another
process is using the CPU. The fraction is the portion of the buffer
containing samples. For the play direction, we see that the buffer is
not entierly full, but there are enough samples to continue playing
smoothly. So these are just warnings, there are no underruns at sndiod
level.

I'd suggest you quickly check if there are underruns at firefox level:
Use "-ddd" sndiod options. Whenever firefox underruns, sndiod will
log:

firefox0 vol=127,pst=run: xrun, pause cycle

Is there a new message every time you hear a glitch?

(note that certain programs just stop providing data to sndiod in
order to pause, which will flood you with above messages, but it is
not a problem)

Re: Behringer UMC404HD USB soundcard with OpenBSD 7.1.

[Alexandre Ratchov]

On Sat, Jul 16, 2022 at 07:08:03PM +0200, Brian Durant wrote:
> 
> On 7/16/22 6:26 PM, Alexandre Ratchov wrote:
> > On Sat, Jul 16, 2022 at 05:37:35PM +0200, Brian Durant wrote:
> > > On 7/16/22 3:54 PM, Alexandre Ratchov wrote:
> > > > On Sat, Jul 16, 2022 at 03:36:18PM +0200, Brian Durant wrote:
> > > > > # mixerctl -f /dev/audioctl1
> > > > > mixerctl: /dev/audioctl1: Device not configured
> > > > > 
> > > > > # dmesg
> > > > forgot to mention: connect and power on the audio interface first ;-)
> > > It was. This time I waited until boot was complete, before connecting the
> > > USB cable...
> > > 
> > ...
> > 
> > > uhub3: port 1, set config 0 at addr 6 failed
> > > uhub3: device problem, disabling port 1
> > > 
> > sorry, I missed these lines, this is when you connected the device,
> > right?
> > 
> > The device doesn't even attach, so not surprising it doesn't work. I
> > don't know what could cause this maybe weak power?
> > 
> > Do you have an external power source, if not could you try with it?
> I think so, I was multitasking at the time... Interesting and even more
> interesting. Yes, the power supply that came with the unit is plugged in and
> functioning on the UMC404HD. I had a UMC202HD lying around the house, that I
> just tried, which is powered through the USB cable and that works fine with
> OpenBSD. Only the powered UMC404HD had issues.
> 

This reminds me a very basic MIDI keyboard (single usb1.1 bulk pipe)
that caused the same "port disabled" problem on all of my machines. It
managed to attach once every ~20 times though.

IIRC, the host didn't manage to reload the the device descriptor. I
tried to add delays at various places, tweak descriptor size, retry
many times but this didn't help. It seems that the host did something
that locks the device before the initial request to reload the
descriptor.

The device had a "programming mode" (hold a switch during attach), in
which it always attached; this mode the keyboard was not usable, so
probably not initialized.

Interestingly, all the "port disabled" problems I encountered the last
decade were caused by audio/MIDI equipment. The only specificity of
the audio equipment is that it has big analog circuits that may
consume more power and may take more time to settle. Cranking the
relevant delay in usbd_new_device() didn't help.

Cc'ing mpi@, just in case this rings a bell.

Re: Behringer UMC404HD USB soundcard with OpenBSD 7.1.

[Alexandre Ratchov]

On Sat, Jul 16, 2022 at 05:37:35PM +0200, Brian Durant wrote:
> On 7/16/22 3:54 PM, Alexandre Ratchov wrote:
> > On Sat, Jul 16, 2022 at 03:36:18PM +0200, Brian Durant wrote:
> > > 
> > > # mixerctl -f /dev/audioctl1
> > > mixerctl: /dev/audioctl1: Device not configured
> > > 
> > > # dmesg
> > forgot to mention: connect and power on the audio interface first ;-)
> 
> It was. This time I waited until boot was complete, before connecting the
> USB cable...
> 

...

> 
> uhub3: port 1, set config 0 at addr 6 failed
> uhub3: device problem, disabling port 1
> 

sorry, I missed these lines, this is when you connected the device,
right?

The device doesn't even attach, so not surprising it doesn't work. I
don't know what could cause this maybe weak power?

Do you have an external power source, if not could you try with it?

Re: Behringer UMC404HD USB soundcard with OpenBSD 7.1.

[Alexandre Ratchov]

On Sat, Jul 16, 2022 at 03:36:18PM +0200, Brian Durant wrote:
> 
> 
> # mixerctl -f /dev/audioctl1
> mixerctl: /dev/audioctl1: Device not configured
> 
> # dmesg

forgot to mention: connect and power on the audio interface first ;-)

Re: Behringer UMC404HD USB soundcard with OpenBSD 7.1.

[Alexandre Ratchov]

On Sat, Jul 16, 2022 at 08:26:49AM +0200, Brian Durant wrote:
> I have thus far been using an audio direct out to my speakers, but would
> like to get my USB soundcard working in OpenBSD. Without the soundcard,
> (direct connection) everything works fine. With the soundcard, no audio at
> all. I have tried the following as per the OpenBSD FAQ:
> 
> # rcctl set sndiod flags -f rsnd/0 -F rsnd/1
> # rcctl restart sndiod
> sndiod(ok)
> sndiod(ok)
> 
> I have rebooted the system, tried Cmixer and adjusted output gradually to
> 100%, but did not get any sound. I have consulted the list archive, but
> nothing, except to note what I already knew, that Behringer soundcards are
> class compliant. I use this card on Windows 11, Linux and FreeBSD, so I know
> that it works. I have made no major adjustments to the unit itself. Sooo, I
> have hit a bit of a dead end. Anyone out there that can provide some help? I
> am trying to get this to work by testing YouTube in Firefox, both of which
> work with a direct audio connection (midi jack cable)...

could you send the output of:

mixerctl -f /dev/audioctl1
and:
dmesg

Re: Web MIDI, Firefox, OpenBSD.

[Alexandre Ratchov]

On Fri, Jul 15, 2022 at 02:28:37PM +0200, Brian Durant wrote:
> On 7/15/22 12:54 PM, Alexandre Ratchov wrote:
> 
> > On Thu, Jul 14, 2022 at 10:05:43AM +0200, Brian Durant wrote:
> > > On a possibly related issue to my browser access to file system problem, 
> > > has
> > > anyone been able to get Web MIDI working with Firefox on OpenBSD 7.1? 
> > > Here I
> > > am referring to bandcamp.com and flowkey.com in particular. Neither site
> > > appears to be receiving any MIDI signal despite an Akai LPK25 (for 
> > > testing)
> > > being registered by the system at umidi0. Flowkey requires ffmpeg to be
> > > installed, as well as prompting for the Jazz MIDI extension to be 
> > > installed.
> > > Flowkey tabs crash and never make a MIDI connection. This has never 
> > > happened
> > > to me with Win 11, Linux, of FreeBSD. The Bandcamp site simply doesn't
> > > register a MIDI device connected to the system, but doesn't crash the tab.
> > > Again, any constructive advice is welcomed.
> > > 
> > > 
> > OpenBSD ports has no MIDI support. A quick look at firefox sources
> > suggest it's using is library:
> > 
> > https://github.com/boddlnagg/midir
> > 
> > which doesn't have sndio backend.
> 
> Many thanks about the information regarding Web MIDI, Firefox and midir. No
> wonder this has been driving me mad. I had yet to look systematically at
> ports to see what programs using MIDI were available, as I have been so busy
> with the browser issues, so it is interesting that you state that MIDI
> programs are lacking in ports. What do other users do? To my mind, OpenBSD
> has excellent support for recognizing MIDI devices, and excellent audio
> support (sndio) as well, which would make it an excellent OS for music
> production... At the very least, it should be feasible to get a USB MIDI
> keyboard working with fluidsynth (Qsynth) according to the OpenBSD FAQ
> (Multimedia), but I admittedly have yet to be successful at getting that
> working either...
> 

To make fluidsynth work (applies to any real-time softsynth), first
lower sndio latency, example:

doas rcctl set sndiod flags "-z 128"
doas rcctl restart sndiod

Install fluidsynth and generaluser-gs-soundfont pacakges. In one
terminal start fluidsynth:

fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2

At this point, fluidsynth listens for incoming MIDI messages on the
default "midithru/0" port. To send MIDI messages from your keyboard
(probably "midi/0") to it, try:

midicat -d -q midi/0 -q midithru/0

Re: Web MIDI, Firefox, OpenBSD.

[Alexandre Ratchov]

On Thu, Jul 14, 2022 at 10:05:43AM +0200, Brian Durant wrote:
> On a possibly related issue to my browser access to file system problem, has
> anyone been able to get Web MIDI working with Firefox on OpenBSD 7.1? Here I
> am referring to bandcamp.com and flowkey.com in particular. Neither site
> appears to be receiving any MIDI signal despite an Akai LPK25 (for testing)
> being registered by the system at umidi0. Flowkey requires ffmpeg to be
> installed, as well as prompting for the Jazz MIDI extension to be installed.
> Flowkey tabs crash and never make a MIDI connection. This has never happened
> to me with Win 11, Linux, of FreeBSD. The Bandcamp site simply doesn't
> register a MIDI device connected to the system, but doesn't crash the tab.
> Again, any constructive advice is welcomed.
> 
> 

OpenBSD ports has no MIDI support. A quick look at firefox sources
suggest it's using is library:

https://github.com/boddlnagg/midir

which doesn't have sndio backend.

Re: USB audio garbled over time

[Alexandre Ratchov]

On Thu, Jun 30, 2022 at 03:11:18PM -0700, Courtney wrote:
> Hello everyone,
> 
> I am running OpenBSD -current branch right now. I have a FiiO E10k plugged
> into my board. Here is the part of the dmesg when it is connected
> 
> Jun 30 15:02:48 towerDefense /bsd: uaudio0 at uhub0 port 14 configuration 1
> interface 2 "FiiO DigiHug USB Audio" rev 1.10/0.01 addr 6
> Jun 30 15:02:48 towerDefense /bsd: uaudio0: class v1, full-speed, sync,
> channels: 2 play, 2 rec, 3 ctls
> Jun 30 15:02:48 towerDefense /bsd: audio1 at uaudio0
> 
> I have been trying to pinpoint an issue where after a time of being away
> from my computer,
> when I come back my audio isn't behaving. I'm not an audio guy so I will
> probably mess
> up some terms, sorry. The pitch sounds right but the audio has a lot of
> static in it. Normally
> this happens after I walk away from my computer and come back maybe an hour
> later. It
> doesn't go into any sleep state, only power efficiency mode that the
> monitors handle on their
> own. An rcctl restart sndiod doesn't solve the issue, I have to physically
> unplug and plug it,
> then run rcctl restart sndiod and all is back to normal. Nothing appears in
> the logs for me
> to report. What can I look at when I encounter this again to see what is
> being changed
> (if anything)? Or, maybe my hardware is just progressively giving up the
> ghost? This has been
> happening for a while now.

When you walk away is it playing? you can run:

audioctl -f /dev/audioctl1

to check device state before and after the walk (empty "mode" means
it's closed, "pause=0" means it's playing or recording)

smtpd: return tempfail if no valid fcrdns: good or bad?

[Alexandre Ratchov]

I noticed that most of the spam that spamd(8) doesn't catch comes from
machines with no valid FCrDNS and that all legitimate mails used valid
FCrDNS.

Certain [1] recommend to return 550 in case of invalid FCrDNS, but if
I understand correctly, 550 is a permanent error. So this may block
legitimate mails in case of temporary DNS lookup failures, which
happens from time to time.

So I'm tempted to use 421 instead of 550, as follows:

filter check_rdns phase connect match !rdns \
disconnect "421 DNS lookup failure, please try again later."
filter check_fcrdns phase connect match !fcrdns \
disconnect "421 No valid FCrDNS, please try again later."

A quick test shows that this discards a lot of the spam, but I'm not
100% sure about whether this could hurt legitimate mail, hence my
question here.

Am I missing something? Anyone is successfully using this approach?

[1] 
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/

Re: White noise with audio over headphones

[Alexandre Ratchov]

On Thu, Jun 16, 2022 at 09:46:18AM -0500, Rob Whitlock wrote:
> On Wed, Jun 15, 2022 at 11:27 PM Alexandre Ratchov  wrote:
> 
> On Wed, Jun 15, 2022 at 02:59:40PM -0500, Rob Whitlock wrote:
> > I have a Lenovo T450 that plays audio over the speakers and headphones
> but
> > when the headphones are used there is some white noise playing all the
> time
> > as well as the audio. This white noise is not there with Windows 10 or
> > Linux. OpenBSD recognizes the audio codec as a Realtek ALC292 but Linux
> and
> > the spec sheet for my laptop say it's a Realtek ALC3232. I suspect this
> > might be causing the error but I'm not sure how to fix it. There was no
> > mention of an ALC3232 in /usr/src/sys/dev/pci/azalia_codec.c while there
> > was for ALC292.
> >
> 
> Hi,
> 
> Could you try:
> 
>   mixerctl inputs.mix2_source=dac-0:1
> 
> and check if noise level changes?
> 
> 
> That did the trick. Thanks! What made you think of this suggestion?

from mixerctl output:

outputs.hp_source=mix2
inputs.mix2_source=dac-0:1,mix  { dac-0:1 mix }
inputs.mix_source=spkr3,mic2,beep  { spkr3 mic2 beep }

The signal for "hp" (the headphones) seems to be the mix of the DAC
(what plays audio samples) and the "mix" node. The "mix" node is the
mix of spkr3, mic2, beep

My guess was that one of the sources is not properly wired or
configured and generates noise.

Removing "mix" from the headphone sources, removes the possible source
of noise (one of spkr3, mic2, and beep)

Re: White noise with audio over headphones

[Alexandre Ratchov]

On Wed, Jun 15, 2022 at 02:59:40PM -0500, Rob Whitlock wrote:
> I have a Lenovo T450 that plays audio over the speakers and headphones but
> when the headphones are used there is some white noise playing all the time
> as well as the audio. This white noise is not there with Windows 10 or
> Linux. OpenBSD recognizes the audio codec as a Realtek ALC292 but Linux and
> the spec sheet for my laptop say it's a Realtek ALC3232. I suspect this
> might be causing the error but I'm not sure how to fix it. There was no
> mention of an ALC3232 in /usr/src/sys/dev/pci/azalia_codec.c while there
> was for ALC292.
> 

Hi,

Could you try:

mixerctl inputs.mix2_source=dac-0:1

and check if noise level changes?

Re: Firefox and stuttering USB audio

[Alexandre Ratchov]

On Thu, May 26, 2022 at 02:25:16PM +0200, Peter Fröhlich wrote:
> Just FYI, when I updated from a smooth 7.0 to 7.1 about a week ago, I
> started experiencing audio/video stuttering that I did not before. I
> am unclear on what exactly the problem is, whether it's the kernel, a
> driver, Firefox, etc. I just know that I went from a "no audio/video
> issues whatsoever" X230 to a "I get about 20 seconds before the next
> stutter will happen" X230. :-/
> 

How many tabs/windows do you have? With -current firefox:

$ ps ax | grep firefox | wc -l
  40

which might increase the probability of stuttering.

Re: azalia: no sound

[Alexandre Ratchov]

On Mon, May 02, 2022 at 02:47:45PM +0300, Kirill Kaplin wrote:
> > OpenBSD detected 3 sound cards for you. From what I recall, the one on
> > the HDMI video output (associated to your video card) is not
> > supported, so no sound there.
> > Maybe the sound goes to your envy0, ESI Julia sound card. Could you
> > check with some phones or speakers?
> Sound goes to Realtek if I do nothing (currently it goes to envy thanks to
> sndio flags), I tried every output, nothing helps.
> 

I've a very similar machine with both the same Realtek ALC892 codec
and the ESI-Julia card.

I just connected amplifier to the green jack and it makes sound when I
play sounds using azalia, with the default settings.

According to your mixerctl output, your're using the green jack (aka
line-out) as well; your audioctl tests show that the azalia host
works. So I'm very surprised it doesn't work for you

Could you check the physical connections? Could you try to set the
outputs.master to the maximum? Do you know of ther operating systems
manage to make sounds?

Below are my settings:

$ dmesg | grep -e ^azalia0 -e ^audio0
azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi
azalia0: codecs: Realtek ALC892, Intel/0x2806, using Realtek ALC892
audio0 at azalia0

$ mixerctl | grep grn
inputs.mix_source=mic,mic2,line-in,hp,line-grn,line-blk,line-org,line-gry
inputs.mix_line-grn=120,120
outputs.line-grn_source=mix2
outputs.line-grn_mute=off
outputs.line-grn_dir=output
outputs.line-grn_boost=off
outputs.line-grn_eapd=on
record.adc-2:3_source=mic,mic2,line-in,hp,line-grn,line-blk,line-org,line-gry,mix
record.adc-0:1_source=mic,mic2,line-in,hp,line-grn,line-blk,line-org,line-gry,mix
outputs.line-grn_sense=plugged
outputs.master.slaves=dac-0:1,line-grn,hp,dac-8:9

FWIW, your envy card as it sounds much better so, I'm suggesting using
it after this problem is solved.

Re: trick to get sound recording and playing under -current?

[Alexandre Ratchov]

On Sat, Mar 19, 2022 at 08:51:15AM +0100, Peter J. Philipp wrote:
> Hi,
> 
> I see some code changed, but I also lost my working configuration after
> rebuilding my workstation.  I have:
> 
> pjp@polarstern$ env | grep -i audio
> AUDIORECDEVICE=rsnd/1
> AUDIOPLAYDEVICE=rsnd/0
> pjp@polarstern$ ps auxww|grep sndiod
> _sndiop  44358  0.0  0.0  2656   952 ??  IpU 8:32AM0:00.00 sndiod: 
> helper (sndiod)
> _sndio   78064  0.0  0.0  2664   844 ??  I /usr/bin/sndiod -f rsnd/0 -f rsnd/1
> pjp  70648  0.0  0.0   192   588 pe  R+/18:43AM0:00.00 grep sndiod
> 
> 
> This doesn't play anything, nor does it record anything.  What am I doing
> wrong?
> 
> When I unset these environment variables and start audacity:
> 
> after setting:  kern.audio.record: 0 -> 1
> 
> I cannot record sound, but at least I can play sound.  How do I get the mic
> working?  Here is a dmesg of audio:
> 
> audio0 at azalia1
> audio1 at uaudio0
> ..
> uaudio0 at uhub2 port 3 configuration 1 interface 3 "Logitech Webcam C310" 
> rev 2.00/0.10 addr 8
> uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls
> 
> I'm stumped I tried all sorts of things to get this to work...
> 

Sorry, there's no way (yet) to combine one play-only and one rec-only
devices into a single full-duplex device.

Above env. vars allow certain programs that don't use full-duplex to
use different devices depending on if they need play-only mode or
rec-only mode.

I'd suggest getting a full-duplex device, there are decent cheap ones
ones, including TRRS to usb "converters" that allow phone headsets to
be used for telephony.

Re: No sound on ThinkPad X220 using current snapshot

[Alexandre Ratchov]

On Mon, Feb 14, 2022 at 01:11:09PM +0100, Dirk-Wilhelm Peters wrote:
> Hi,
> 
> after a recent update to the latest snapshot on my ThinkPad X220, there
> is no sound after returning from suspend mode. The problem persists
> even after a reboot. I have to shutdown/restart the machine to enable
> audio output again. Headphone output is not affected.
> 

This is recent regression, right?

FWIW mixer settings are saved during suspend and restored on
resume. Working headphones suggests this may be caused by parts of the
system (speaker amplifiers) not being powered.

Re: Who is responding to my audio volume keys?

[Alexandre Ratchov]

On Mon, Dec 20, 2021 at 09:59:29AM +0100, Richard Ulmer wrote:
> Hi Alexandre, Hi Christian,
> thanks for you responses! In the meantime Ralf Horstmann had also
> contacted me and helped me find a workaround.
> 
> Alexandre Ratchov  wrote:
> > Keyboard volume keys control volume of first audio device.
> 
> We probably have different definitions of 'first audio device', but even
> if I put 'rcctl set sndiod flags -f rsnd/1' into /etc/hotplug/attach and
> 'rcctl set sndiod flags -f rsnd/0' into /etc/hotplug/detach, so that
> only one audio device is configured at a time, the volume keys only work
> for the internal device.
> 

Sorry, I was refering to the first instance of the audio(4) driver,
a.k.a the "audio0 at ..." in dmesg output. The volume keys are handled
entierly inside the kernel with direct calls from the wskbd driver to
audio driver, so the logic is completely out of the scope of sndiod or
any program.

Re: Who is responding to my audio volume keys?

[Alexandre Ratchov]

On Sat, Dec 18, 2021 at 10:27:19AM +0100, Richard Ulmer wrote:
> Hi all,
> with the help of https://www.openbsd.org/faq/faq13.html I have set up a
> USB sound card for my laptop. I use when it is attached and the internal
> one when it is not (just like the example in FAQ #13).
> 
> This works nicely, but one thing is missing: The volume keys on my
> Laptop (ThinkPad T450) don't change the volume when the USB sound card
> is used. They work when the internal sound card is used, but I don't
> recall ever configuring this. There has to be someone listening to these
> keys, but I couldn't find who it is.
> 
> I can see the volume key events with xev(1) and the output of 'sndioctl
> output.level' changes when pressing the keys (only for the internal
> sound card), so I assume the volume is not controlled "by the hardware
> itself".
> 
> Can someone point me to the relevant man page?
> 

Keyboard volume keys control volume of first audio device. This is not
configurable. Unfortunately key strokes are not consumed, so they
propagate to Xorg and generate XF86XK_Audio{Raise,Lower}Volume which
may cause programs to change the volume a second time in a different
way.

I'd suggest to configure in your window manager hot-keys of your
choice to call sndioctl.

Alternatively, here's a tiny program to control sndiod(8) volume with
ctrl-alt-plus and ctrl-alt-minus; I mostly use it because my keyboard
has no volume keys but I realise it may be useful for setups with
multiple devices, so I throw it here:

https://caoua.org/alex/obsd/sndiokeys.tar.gz

HTH

Re: Audio codec support for new(er) Framework laptops?

[Alexandre Ratchov]

On Fri, Oct 29, 2021 at 09:13:57AM +, aval...@posteo.net wrote:
> Hi Misc!
> 
> Does anyone know whether the Tempo 92HD95B audio codec is supported?
> 
> https://temposemi.com/products/pclaptop-hd/92hd95/
> 
> I'm considering getting the Framework laptop and Joshua Stein's website
> indicates that at this point, it's pretty well supported
> 
> https://jcs.org/2021/08/06/framework
> 
> But Framework is changing audio codecs on their next batches of
> machines.
> 
> https://frame.work/blog/solving-for-silicon-shortages
> 
> Thus far, I haven't been able to find a way to check whether the new
> audio chip is supported, as "fully supported in both Windows and Linux"
> doesn't actually say much, and Tempo's answer to "how do I get a driver"
> is "Ask our OEM partner that actually made the computer in question"
> 
> I *have* identified that the chip is compatible with Intel's HD audio
> interface, so from what I'm reading in azalia's man page, I think it
> *should* have support already under azalia, but I'll admit, the
> technical specs go a bit over my head.
> 
> If anyone can clarify this for me, I'd really appreciate it.
> 

Short answer: virtually any HDA codec is supported and there are good
chances that sound will just work on this laptop.

Long answer: The HDA spec. allows the driver (i.e. azalia(4)) to
control all HDA-compatible codecs in a uniform way, so any past or
future codec is supposed to just work with the current driver,
provided the codec is HDA compatible.

There are rare hardware bugs or "creative" ways of connecting the
codec to the HDA host that cause problems, most of them are handled by
quirks in the azalia(4) driver.

There are few laptops that have HDA codecs that require firmware to
make advanced features work.  Certain recent laptops come with
microphones that are not physically connected to the HDA codec
(instead they use a secondary audio device OpenBSD doesn't support
yet).

Re: mpd - All audio outputs are disabled

[Alexandre Ratchov]

On Mon, Oct 18, 2021 at 03:04:20PM -0400, Mario St-Gelais wrote:
> Hum, I had subject problem in the past following an upgrade, It happened
> again, yet, I cannot remember what the heck I used to do to solve it.
> 
> I vaguely remember it was a stupid thing.  Any hint please?
> 
> I can do aucat -i file.wav no problem.
> Changed ownership of audio0 to my username
> 

audio and MIDI-related files in /dev are supposed to be owned by root,
by default only sndiod(8) uses them directly.

Most probably _mpd user and you are trying to connect to sndiod
simultaneously.

If so, you can authorize _mpd to connect to your sndio session by
copying your ~/.sndio/cookie to _mpd home directory. There's a short
explanation in the "Authentication" section of sndio(7).

Re: envy(4) timeouts with ESI Wave Terminal 192M

[Alexandre Ratchov]

On Tue, Aug 17, 2021 at 03:31:55PM +0200, Jan Stary wrote:
> This is current/amd64 on an older PC (full dmesg below)
> using an ESI Wave Terminal 192M attaching as
> 
> envy0 at pci4 dev 4 function 0 "IC Ensemble Envy24PT/HT Audio" rev 0x01: apic 
> 2 int 20
> envy0: unknown 1724-based card, 2 inputs, 8 outputs
> audio0 at envy0
> midi0 at envy0: 
> 
> This is what audioctl and mixerctl show
> as the exposed controls:
> 
> # audioctl
> name=envy0
> mode=
> pause=1
> active=0
> nblks=4
> blksz=480
> rate=48000
> encoding=s24le4msb
> play.channels=8
> play.bytes=0
> play.errors=0
> record.channels=2
> record.bytes=0
> record.errors=0
> 
> # mixerctl -av
> outputs.line-0_source=play-0  [ line-0 line-1 play-0 ]
> outputs.line-1_source=play-1  [ line-0 line-1 play-1 ]
> outputs.line-2_source=play-2  [ line-0 line-1 play-2 ]
> outputs.line-3_source=play-3  [ line-0 line-1 play-3 ]
> outputs.line-4_source=play-4  [ line-0 line-1 play-4 ]
> outputs.line-5_source=play-5  [ line-0 line-1 play-5 ]
> outputs.line-6_source=play-6  [ line-0 line-1 play-6 ]
> outputs.line-7_source=play-7  [ line-0 line-1 play-7 ]
> record.enable=sysctl  [ off on sysctl ]
> 
> Is this expected? With other audio devices
> I usualy also see some mixer and volume controls.
> 
> 
> I am seeing timeouts with both recording and playback:
> 
>   $ aucat -o file.wav
>   $ default: audio device gone, stopping
> 
>   $ aucat -i file.wav
>   $ default: audio device gone, stopping
> 
> While this happens, dmesg says:
> 
>   envy0: output DMA halt timeout
>   envy0: input DMA halt timeout
>   envy0: output DMA halt timeout
>   envy0: input DMA halt timeout
> 
> How can I help debug this?
> 

Hi,

You could start by enabling ENVY_DEBUG option rebuild kernel and see
if you get additional information.

The "DMA halt timeout" errors probably indicate that DMA never
started, which is very strange. You can check this by writing zeros to
/dev/audio1 and see if there are interrupts (ex. with "systat
vmstat").  No interrupts indicates DMA didn't start.

Basically, these cards have an Envy chip which is the interface to the
PCI bus and handles DMA and interrupts. The Envy chip is connected to
one or more DACs and/or ADCs (or to a complete AC97-style codec). The
Envy chip simply reads data from hosts memory and sends it to the DAC.

For sound to work ADC/DACs may need to be configured; this is done
either by setting GPIO pins or sending few bytes through a I2C link.
As your card is not known by OpenBSD driver, the code for ADC/DAC
initialization is missing. You can figure-out what ADC/DAC your card
is using by looking at the ICs on the board (the big one is the Envy
chip, aka ICE, the other big one(s) are the ADC/DAC), then google
for the corresponding datasheets

The interesting part in your dmesg is that DMA doesn't seem to start,
I thought DMA would start even if the ADC/DAC is not initialized, but
I may be wrong.

Re: send ctrl-alt-f1 to user app

[Alexandre Ratchov]

On Fri, Jul 02, 2021 at 01:55:26PM +0300, Gregory Edigarov wrote:
> Hello,
> 
> please remind how to do that?
> 
> in my case it changes to the vterm0, that is ok,  but now I my app to
> react, not change terminal
> thank you.
> 

Never tried it, but this reminded me Xorg(1):

   Ctrl+Alt+F1...F12
   For systems with virtual terminal support, these keystroke
   combinations are used to switch to virtual terminals 1 through
   12, respectively.  This can be disabled with the DontVTSwitch
   xorg.conf(5) file option.

HTH

Re: aucat -c playback channels confusion

[Alexandre Ratchov]

On Tue, May 25, 2021 at 03:45:17PM +0200, Jan Stary wrote:
> This is current/amd64. I am trying to use the -c option of aucat,
> specifying the channels to be played from a multichannel file.
> 
> As an example, here is a quad audio file produced by sox:
> 
> $ sox -n -b 16 quad.wav synth 10 sin 200 sin 300 sin 400 sin 600 gain -6
> $ soxi quad.wav
> 
> Input File : 'quad.wav'
> Channels   : 4
> Sample Rate: 48000
> Precision  : 16-bit
> Duration   : 00:00:10.00 = 48 samples ~ 750 CDDA sectors
> File Size  : 3.84M
> Bit Rate   : 3.07M
> Sample Encoding: 16-bit Signed Integer PCM
> 
> 
> Now trying to use aucat -c to play the individual channels
> doesn't seem to do what it says:
> 
> $ aucat -dd -c 0:0 -i quad.wav
> quad.wav: skipped unknown chunk
> quad.wav,pst=cfg: play, chan 0:3, 48000Hz, s16le, bytes 80..3840080, vol 32768
> default: 48000Hz, play 0:3, 36 blocks of 480 frames
> quad.wav,pst=cfg: allocated 17280 frame buffer
> cmap: nch = 4, ostart = 0, onext = 0, istart = 0, inext = 0
> quad.wav,pst=ini: chain initialized
> quad.wav,pst=run: started
> started
> ^Cquad.wav,pst=ini: stopped
> stopped
> quad.wav,pst=ini: closed
> 
> 
> Indeed quad.wav has channels 0:3, but why does auact play channels 0:3
> with -c 0:0 specified? Specifying other channels seem even more confusing:
> 
> $ aucat -dd -c 2:2 -i quad.wav
> quad.wav: skipped unknown chunk
> quad.wav,pst=cfg: play, chan 2:5, 48000Hz, s16le, bytes 80..3840080, vol 32768
> default: 48000Hz, play 0:5, 36 blocks of 480 frames
> quad.wav,pst=cfg: allocated 17280 frame buffer
> cmap: nch = 4, ostart = 2, onext = 0, istart = 0, inext = 0
> quad.wav,pst=ini: chain initialized
> quad.wav,pst=run: started
> started
> ^Cquad.wav,pst=ini: stopped
> stopped
> quad.wav,pst=ini: closed
> 
> Now it considers quad.wav to have channels 2 to 5
> and it plays channels 0:5, given -c 2:2.
> 
> Maybe I am misunderstanding the -c option
> (or what the -dd messages say):
> 
>   -c min:max The range of audio file channel numbers.
>  The default is 0:1, i.e. stereo.
> 
> When playing a file with aucat -i, does that mean
> "use these channels from the file"?
> 
> If not, how does one specify "play just channel 2, out of 0,1,2,3"?
> 
> There is a chunk that aucat skips; this is what sndfile-info says:
> 
> File : quad.wav
> Length : 384080
> RIFF : 384072
> WAVE
> fmt  : 40
>   Format: 0xFFFE => WAVE_FORMAT_EXTENSIBLE
>   Channels  : 4
>   Sample Rate   : 48000
>   Block Align   : 8
>   Bit Width : 16
>   Bytes/sec : 384000
>   Valid Bits: 16
>   Channel Mask  : 0x33 (L, R, Ls, Rs)
>   Subformat
> esf_field1 : 0x1
> esf_field2 : 0x0
> esf_field3 : 0x10
> esf_field4 : 0x80 0x0 0x0 0xAA 0x0 0x38 0x9B 0x71 
> format : pcm
> fact : 4
>   frames  : 48000
> data : 384000
> End
> 
> 
> Sample Rate : 48000
> Frames  : 48000
> Channels: 4
> Format  : 0x00130002
> Sections: 1
> Seekable: TRUE
> Duration: 00:00:01.000
> Signal Max  : 16424 (-6.00 dB)
> 
> 
> With 1 second instead of 10 seconds of audio (synth 1) the file
> is small enough, I am attaching it.
> 
> Thanks for any clue.
> 

Hi,

The -c, -e, and -r options are used to specify file's channels,
encoding and rate in case they are undefined, typically for raw data
files. The .wav file header of quad.wav contains the number of
channels (but not the initial channel). So, in your example, the
number of channel is taken from the .wav header, that's why you hear
all channels. The -c option is used only to determine the starting
channel.

For output .wav files -c make sense, though. For instance:

aucat -n -i quad.wav -c 1:1 -o quad-1.wav

extracts channel 1 into a mono file. Here -c 1:1 specifies channels
selection of the output file. Then, playing quad-1.wav will, in turn,
play channel 1 of the quad.wav file.

Re: Bidirectional audio between OpenBSD sndiod <-> Debian pulseaudio

[Alexandre Ratchov]

On Mon, May 10, 2021 at 07:05:49PM +, Martin wrote:
> Hi,
> 
> Great experience! But I have no possibility to recompile each sound producer 
> software to have sndio support.
> 
> So my way is to use additional layer of well implemented sound architecture 
> and it add additional layer to sound system for sure.
> 
> I've tried to use alsa-sndio module from https://github.com/Duncaen/alsa-sndio
> 
> Module builds successfully, but
> 
> $ sudo alsactl init
> returns it can't find any audio hardware (Debian system is headless and run 
> on VM).
> 
> Tried to add snd-dummy module from 
> https://www.alsa-project.org/main/index.php/Matrix:Module-dummy
> $ sudo modprobe snd-dummy
> 
> $ sudo alsactl init
> Found hardware: "Dummy" "Dummy Mixer" "" "" ""
> 
> But how to output from alsa-sndio module using alsa is not clear for me.
> 
> I've created /etc/asound.conf as required by developers of alsa-sndio module.
> 
> $ cat /etc/asound.conf
> pcm.!default (
>  type sndio
>  device "snd@192.168.33.1/0"
> 
> alsa don't use this config.
> 
> Do you have some experience how to use alsa modules to iteract with OpenBSD 
> sndiod server?
> 

Not much, sorry.

Did you check that the VM can talk to the host? You could do so by
installing the sndio library and utils on the VM and test with aucat
that everything works.

Re: Bidirectional audio between OpenBSD sndiod <-> Debian pulseaudio

[Alexandre Ratchov]

On Sat, May 08, 2021 at 10:29:35AM +, Martin wrote:
> Hi list,
> 
> It is great to have bidirectional audio between OpenBSD host and Debian guest 
> (headless). I hope I move in a right way to make this thing working.
> 
> Required configuration:
> mic-in on OpenBSD host >> Debian VMM guest
> audio-out from Debian VMM guest >> OpenBSD host
> 
> Does anybody using pulseaudio or any other driver to have
> bidirectional network audio stream between VMM guest and OpenBSD
> host system?

Hi,

These days I use a simiar setup with Alpine running in a
OpenBSD-hosted VM. The main purpose of sndiod -L option is to handle
such setups (don't forget to copy your ~/.sndio/cookie on the VM). In
the past, I used a lot Debian, but on a real machine.

I didn't try to involve pulseaudio or any alsa tweakery, to limit the
number of audio software layers and in turn get the maximum audio
stability.  So I just rebuild the software I needed with sndio support
enabled (that was mostly firefox and few audio players).

Re: .profile not being loaded (ksh) when opening shell in X

[Alexandre Ratchov]

On Mon, Apr 26, 2021 at 09:26:19PM +, tetrahe...@danwin1210.me wrote:
> I have some custom additions to my $PATH. They're defined in ~/.profile and
> they are correctly loaded when I log in from a text console.
> 
> When I log in to X (cwm) and open a terminal window, $PATH does not contain
> the entries.
> 
> I tried `chmod +x` on my .profile but that didn't help.
> 
> Both the text console and the X terminal window are using ksh.
> 
> When I call `/bin/ksh -l` then the resulting shell contains the correct
> additions to $PATH.
> 
> It looks like the custom $PATH is not being passed from the login shell on
> downwards, since ~/.profile is only read by a login shell.
> 
> ~/.kshrc is (according to ksh(1)) read by every spawning shell, but I don't
> see any documentation or examples on the Internet where someone defined
> their $PATH in ~/.kshrc ...
> 
> What's the correct way to set $PATH and have it stick no matter where and
> when the shell is spawned?

If you're using a display manager (xenodm or whatever), you've to
include your .profile in your session login script (X equivalent of
shell's ~/.profile concept), so the envoronment (and other global
login settings) from your .profile become visible to all X programs,
not only xterm. For instance put:

. ~/.profile

at the beginning of our ~/.xsession

If you're using xinit(1), your ~/.profile is already loaded by
the login shell.

Re: How do I change the default per-application sound volume in sndiod?

[Alexandre Ratchov]

On Sun, Apr 25, 2021 at 11:57:42PM -0500, John Batteen wrote:
> Greetings misc,
> 
> I am running 6.9 and am having some difficulty.  I have
> outputs.master=255,255 set in mixerctl.conf (it is the only line in
> the file), but every time I open an application its individual
> volume is set to 0.496.  For example, sndioctl reveals:

> input.level=0.490
> input.mute=0
> output.level=1.000
> output.mute=0
> app/mplayer0.level=0.496
> 
> 
> This is very quiet on my setup and I have to manually adjust the
> volume every time.  I have read the entirety of the sndiod,
> sndioctl, mixerctl, and mixerctl.conf man pages, and I can't find
> anything that tells me how to change that default 0.496 value.  I'd
> rather have it stay at 1.  I've tried modifying every value that was
> set to 126 (0.496 * 255) or anywhere close to it in the default
> mixerctl to 255,255 with mixerctl.conf but it still happens.  Is
> this intended behavior?

When a program exits, its level setting is kept in memory by sndiod;
when the program is started again, it continues with its saved
level. The initial level is 1.

So when the system starts, app/mplayer0.level is supposed to be 1.

Is the problem with mplayer only or with all programs? If it's mplayer
only, is there something in ~/.mplayer/config that could cause this?

Re: sndio: way to play and record from different devices?

[Alexandre Ratchov]

On Mon, Apr 19, 2021 at 09:40:37AM -0500, Ax0n wrote:
> I have a nice microphone attached to a USB sound device, but I'd like to
> rely on my computer's built-in line out for speakers from the same program
> (e.g. Audacity, Firefox). It feels like sndio might have some way to let
> programs use snd/0.play and snd/1.rec, or a way to make snd/1 the default
> device for record and snd/0 the default for play, or maybe even a virtual
> sound device, but I haven't been able to sort out how to make it work.
> 

There's no way (yet) to combine a play-only and a rec-only device into
a single full-duplex one.

Certain programs don't need full-duplex capability and can use two
independent devices; firefox and audacity are not part of them
unfortunately. Sorry.

Re: Microphone not working on Gen8 ThinkPad X1 Carbon

[Alexandre Ratchov]

On Sun, Mar 28, 2021 at 11:58:15AM -0500, Ax0n wrote:
> I initially noticed it when I hopped in a video room on Discord in Firefox
> and folks could see me and I could hear them, but Discord got no audio. It
> turns out, nothing gets any audio. sysctl has audio and video recording
> enabled, and pledge/unveil has been tweaked just a little for firefox to
> pick up the webcam.
> 
> aucat isn't picking up any audio. playing back the WAV I recorded with
> aucat or audacity is just silence. Audacity visibly shows very very low
> audio levels in the "monitor" VU meter when recording, but no amount of
> tinkering with mixerctl, audioctl, or sndioctl seems to make a difference
> in the recorded audio -- it's just silent. Audio output is good (videos on
> youtube for example) and aucat can play other WAV files just fine. I use
> the pianobar package daily to stream Pandora while I work.
> 
> I switched over to the latest snapshot and upgraded packages last night,
> and there's no change.
> 

Hi,

There's a thread about gen7 X1's, here:

https://marc.info/?t=16070737021&r=1&w=2

in short, on these machines, the microphone is not connected to the HD
audio codec (exposed by the azalia driver), but to another "intel
smart sound technology" chip for which OpenBSD has no driver.

If gen8 are the same, until this get fixed, I'd suggest using a
*full-duplex* USB audio headset for audio-conferencing.

There are also cheap -- but good quality, imho -- USB dongles with a
tiny sound card with a TRRS jack that allow most phone headsets to be
used on OpenBSD.

HTH,

-- Alexandre

Re: sound question

[Alexandre Ratchov]

On Mon, Jan 18, 2021 at 12:00:40PM +0100, Peter J. Philipp wrote:
> On Mon, Jan 18, 2021 at 11:29:54AM +0100, Alexandre Ratchov wrote:
> > On Mon, Jan 18, 2021 at 10:16:53AM +0100, Peter J. Philipp wrote:
> > > Hi,
> > > 
> > > I recently switched my desktop workstation to a raspberry pi 4B with 8 GB 
> > > RAM.
> > > Since the sound there doesn't work yet, I got a USB sound card, the make 
> > > of
> > > the sound card is best read from usbdevs -v:
> > > 
> > > addr 08: 0ccd:00b1 TerraTec Electronic GmbH, Aureon 7.1 USB
> > >  full speed, power 500 mA, config 1, rev 0.10
> > >  driver: uaudio0
> > >  driver: ugen0
> > > 
> > > Like the other AUREON card in the usb drivers I put this in usb quirks to 
> > > not
> > > attach as a uhiddev (not sure if that was the right thing to do?).
> > > 
> > > Now to my real question:  mplayer sounds horrible, but iridium sound from 
> > > youtube sounds OK.  There is a lot of static interference when I play with
> > > mplayer.  So what is it doing different than iridium?  I tried messing 
> > > with
> > > audioctl buffer sizes and nblocks but I don't really know what I'm doing 
> > > here,
> > > so I'm writing to the list.  The sound did not improve when I messed with 
> > > the
> > > buffers.
> > > 
> > 
> > Everything looks OK in dmesg. Try to run sndiod in the foreground, ex:
> > 
> > doas sndiod -ddd -a on
> > 
> > and see what happens while mplayer sounds bad. Without stopping
> > mplayer, run audioctl multiple times and see if play.errors or
> > record.errors counters increase continuously.
> > 
> 
> Hmmm this is elusive.  My -current is from December 26th.  When I put the
> sndiod in -ddd -a on mode everything started working well.  Could it be that
> all it needs is a restart after a reboot?  I can crontab that to be 5 minutes 
> after reboot...

The next time it fails, try to stop and start playback to see if this
helps. My bet is that an usb transfer fails (heavy load may cause
this) and the device doesn't recover properly.

> Other than that my sndiod config looks like this in /etc/rc.conf.local:
> 
> sndiod_flags="-f rsnd/0 -f rsnd/1"
> 
> Odd stuff, is the -a on important?  

No, "-a on" is only to force sndiod to keep the device open (or exit
if it can't), it's useful for testing to be sure another process
doesn't grab the device.

Re: sound question

[Alexandre Ratchov]

On Mon, Jan 18, 2021 at 10:16:53AM +0100, Peter J. Philipp wrote:
> Hi,
> 
> I recently switched my desktop workstation to a raspberry pi 4B with 8 GB RAM.
> Since the sound there doesn't work yet, I got a USB sound card, the make of
> the sound card is best read from usbdevs -v:
> 
> addr 08: 0ccd:00b1 TerraTec Electronic GmbH, Aureon 7.1 USB
>  full speed, power 500 mA, config 1, rev 0.10
>  driver: uaudio0
>  driver: ugen0
> 
> Like the other AUREON card in the usb drivers I put this in usb quirks to not
> attach as a uhiddev (not sure if that was the right thing to do?).
> 
> Now to my real question:  mplayer sounds horrible, but iridium sound from 
> youtube sounds OK.  There is a lot of static interference when I play with
> mplayer.  So what is it doing different than iridium?  I tried messing with
> audioctl buffer sizes and nblocks but I don't really know what I'm doing here,
> so I'm writing to the list.  The sound did not improve when I messed with the
> buffers.
> 

Everything looks OK in dmesg. Try to run sndiod in the foreground, ex:

doas sndiod -ddd -a on

and see what happens while mplayer sounds bad. Without stopping
mplayer, run audioctl multiple times and see if play.errors or
record.errors counters increase continuously.

Re: Internal Microphone on Thinkpad X1 Carbon 7th gen not working

[Alexandre Ratchov]

On Thu, Dec 10, 2020 at 10:30:56AM +0100, Anders Damsgaard wrote:
> * Stefan Hagen  [2020-12-10 10:14:35 +0100]:
> 
> > Bodie wrote:
> > > 
> > > 
> > > On 9.12.2020 20:43, Stefan Hagen wrote:
> > > > Hello Zachary,
> > > > 
> > > > Zachary Campbell wrote:
> > > > > Any luck with this? I am also struggling to get the internal
> > > > > mic to work on the X1 Carbon 7th Gen. Have gone through
> > > > > everything discussed here, but still no luck.
> > > > > 
> > > > > My dmesg and mixerctl match those already shared in thread.
> > > > > Happy to share anything else that might be helpful, but after
> > > > > reading through the multimedia FAQ and this thread I am
> > > > > not quite sure where to go next.
> > > > 
> > > > No progress here.
> > > > 
> > > > I think all needed information is in here.
> > > > https://bbs.archlinux.org/viewtopic.php?id=249900
> > > > 
> > > 
> > > That part on SST remind me my problem with audio on T590 under Windows.
> > > For at least two patch builds Windows had issue to picking up wrong
> > > driver for audio. Instead of regular HD Audio they were setting
> > > up SST HD Audio and then output/input were not working.
> > > 
> > > So maybe it is something wrong inside that HW like reporting wrong
> > > capabilities?
> > 
> > Not unlikely as "microphone not working on x1 carbon gen 7" complaints
> > are all over the place. The solution for ms windows is upgrade + use
> > newest drivers. So yes, I assume there's something off that has been
> > fixed in software.
> > 
> > I've seen similar complaints about Dell Laptops that are also using
> > the Realtek ALC285 chip.
> > 
> > If it's just this one chip, then fine, let's ignore it.
> > 
> > Can someone with a X1 Carbon Gen 8 report it working?
> > 
> > Best Regards,
> > Stefan
> > 
> 
> The same issue persists on 8th generation, also reported to dmesg@.
> 
> azalia0 at pci0 dev 31 function 3 "Intel 400 Series HD Audio" rev 0x00: msi
> azalia0: codecs: Realtek ALC285, Intel/0x280b, using Realtek ALC285
> audio0 at azalia0
> 
> Also, the mic is enabled in BIOS and kern.audio.record=1.
> 

AFAIU, all audio components but the internal microphone are connected
to the "Realtek ALC285" codec which is handled by azalia(4). The
internal microphone uses the Intel Smart Sound Technology, which needs
a dedicated driver.

Linux has a driver written by Intel employees, which is around twice
as big as azalia. It's unclear how difficult it would be to write a
openbsd-ish driver that simply makes the hardware work. Sorry.

Meanwhile, if this is for voice calls, I'd suggest either using a
phone headset (the x1 probably has a trrs jack) or a comfortable
full-duplex usb headset; most work way better than the internal
mics/speakers.

Re: sndiod -F does not switch to device

[Alexandre Ratchov]

On Sun, Nov 22, 2020 at 07:48:14PM +0100, Jan Stary wrote:
> This is current/amd64 (dmesg below),
> running /usr/bin/sndiod -f rsnd/0 -F rsnd/1
> 
> While the -F feature works with most USB audio devices I have tried,
> it does not make the switch to use the -F device
> with this USB camera with a builtin microphone.
> It's an Audom AF640 and it attaches as follows:
> 
> uvideo0 at uhub0 port 1 configuration 1 interface 0 "Sunplus IT Co Full HD 
> webcam" rev 2.00/0.05 addr 2
> video0 at uvideo0
> uaudio0 at uhub0 port 1 configuration 1 interface 3 "Sunplus IT Co Full HD 
> webcam" rev 2.00/0.05 addr 2
> uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls
> audio1 at uaudio0
> 
> I can confirm that both the camera and the mike themselves work.
> After plugging it in, sndioctl says
> 
> input.level=0.000
> input.mute=1
> output.level=0.980
> output.mute=0
> server.device=0
> app/rec0.level=1.000
> 
> Notice the server.device=0, meaning it is still using snd/0.
> Notice the zero input level and the muted input.
> Is this intended?
> 
> If I plug a Sennheiser haedset instead, sndioctl says
> 
> input.level=0.800
> input.mute=0
> output.level=0.800
> output.mute=0
> server.device=1
> app/rec0.level=1.000
> 
> switching to the USB device plugged in.
> 
> Is it because the camera's mike has no output channels?
> "channels: 0 play, 1 rec, 2 ctls" - indeed, it only
> records mono and has no playback capabilities.
> 
> According to the manpage
> 
> -F device
> Specify an alternate device to use.  If it doesn't work,
> the one given with the last -f or -F options will be used.
> For instance, specifying a USB device following a PCI device
> allows sndiod to use the USB one preferably when it's
> connected and to fall back to the PCI one when it's
> disconnected. Alternate devices may be switched with the
> server.device control of the sndioctl(1) utility.
> 
> Is the -F device required to have at least one playback
> and pne record channel to "work"?
> 
> Switching with a manual "sndioctl server.device=1"
> doesn't work either: sndioctl still shows server.device=0
> 
> Is this intended?
> How can I further debug this?
> 

Hi,

The -F option works only if two devices have the same capabilities,
this allows to pull the USB cable and continue using the internal
device.

In your case the webcam can't play but sndiod is configured to use
full-duplex mode. From this stand-point, the webcam is not usable and
sndiod tries the next device.

sndiod could/should be changed to simply discard samples to play and
always present the webcam as a full-duplex device (similarly, produce
silence for play-only devices). The code to do so is not there yet,
unfortunately.

Re: Sound/audio onFirefox on 6.8

[Alexandre Ratchov]

On Fri, Oct 23, 2020 at 03:58:55PM -0600, Duncan Patton a Campbell wrote:
> 
> Hey Maurice.  The audio works elsewhere and this looks to be 
> a Zombie Bugzilla bug come back from the dead.  Something
> about needing to directly link to sndio and skip the "cubeb" something...
> 
> Dhu
> 
> This is what shows up on the command line:
> 
> dhu@gate:BSD $ firefox   
> 

Hi,

Could you check /dev permissions? they need to be as follows:

$ ls -al /dev/{audio,audioctl,rmidi}0   
crw-rw  1 root  _sndiop   42,   0 Oct 26 07:23 /dev/audio0
crw-rw  1 root  _sndiop   42, 192 Oct 19 12:20 /dev/audioctl0
crw-rw  1 root  _sndiop   52,   0 Oct 19 12:20 /dev/rmidi0

The /etc/firefox/unveil.* settings need to contain permission
to access ~/.sndio contents:

$ grep sndio /etc/firefox/*   
/etc/firefox/unveil.content:~/.sndio rwc
/etc/firefox/unveil.main:~/.sndio rwc

If above are OK, then run firefox with SNDIO_DEBUG=1 environment
variable exported and show the resulting output, it will reveal why
firefox still can't use the device.

Re: Thinkpad T400 only records from the external mic

[Alexandre Ratchov]

On Sat, Oct 17, 2020 at 07:05:53PM +0200, Jan Stary wrote:
> 
> Strangely, with each of
> 
>$ aucat -i /tmp/file.wav
>$ aucat -o /tmp/file.wav
> 
> it is both
> 
>   play.bytes=562560
>   record.bytes=562560
> 
> that keep growing in audioctl. Is that intended?

Yes. We always play and record at the same time. We do it this way
because this costs virtually nothing and because once playback is
started, we can't start recording properly synchronized to playback.

Re: USB to 3.5mm jack audio adapter

[Alexandre Ratchov]

On Wed, Sep 09, 2020 at 03:49:21PM +0200, Paul de Weerd wrote:
> Hi all,
> 
> As I don't have a microphone to use with my azalia(4) sound card, and
> my webcam only has audio input (no output), I can't use my current
> hardware in firefox to do videoconferencing.  So I purchased (what I
> thought was) a USB to audio adapter[1].  This one simply offers a
> 3.5mm jack connector that I would then plug my existing headphones
> into for full duplex audio.
> 
> Unfortunately, it doesn't seem to be an actual uaudio(4) device:
> 
> uhidev0 at uhub0 port 1 configuration 1 interface 0 "Samsung Electronics 
> Samsung Type-C to 3.5pi gender adapter" rev 2.01/1.33 addr 2
> uhidev0: iclass 3/0, 2 report ids
> uhid0 at uhidev0 reportid 1: input=0, output=63, feature=0
> uhid1 at uhidev0 reportid 2: input=63, output=0, feature=0
> 
> Are there uaudio(4) devices that do provide full duplex (TRRS i.e. mic
> plus speakers) behind a 3.5mm jack?  Anyone have experience with one
> of these they can recommend?  I mean, I have a USB audio device that
> has a 3.5mm jack, but that's output only (TRS, so no microphone).
> 

Hi,

Try searching for "TRRS to USB adapter" then check in the detailed
description that:
  - it's an "external sound card" for computers (Windows/macOS supported)
  - it requires no device driver (means it's USB class-compliant)
  - supports 3.5mm "TRRS" headset jacks (what most phones use)

Re: 6.7 and sound

[Alexandre Ratchov]

On Thu, Sep 03, 2020 at 08:39:45PM -0600, Austin Hook wrote:
> 
> Can't seem to parse the instructions in 
> http://www.openbsd.org/faq/upgrade67.html
> 
> for how to re-enable an ordinary non root user of Firefox or mplayer to 
> output audio.
> 
> mplayer works fine as root, but what command lines are necessary to allow 
> a non root user get sound output?
> 
> let's username is: joeuser
> 

Hi,

Sound is supposed to work by default for regular users. Check if
sndiod(8) is still running and if /dev/audio* have the correct
permissions (normally MAKEDEV, part of the upgrade is supposed to fix
update the permissions).

FWIW, starting 6.7, for improved security, regular users have no
direct access to /dev/audioX anymore. Sound must go through sndiod(8),
which is running by default. For sndiod(8) to access the hardware, the
below device nodes ownership and permissions are needed:

$ ls -al /dev/audio* /dev/rmidi*  
crw-rw  1 root  _sndiop   42,   0 Aug 29 08:00 /dev/audio0
crw-rw  1 root  _sndiop   42,   1 Jul 27 10:16 /dev/audio1
crw-rw  1 root  _sndiop   42,   2 Jul 27 10:16 /dev/audio2
crw-rw  1 root  _sndiop   42,   3 Jul 27 10:16 /dev/audio3
crw-rw  1 root  _sndiop   42, 192 Jul 27 10:16 /dev/audioctl0
crw-rw  1 root  _sndiop   42, 193 Jul 27 10:16 /dev/audioctl1
crw-rw  1 root  _sndiop   42, 194 Jul 27 10:16 /dev/audioctl2
crw-rw  1 root  _sndiop   42, 195 Jul 27 10:16 /dev/audioctl3
crw-rw  1 root  _sndiop   52,   0 Jul 27 10:16 /dev/rmidi0
crw-rw  1 root  _sndiop   52,   1 Jul 27 10:16 /dev/rmidi1
crw-rw  1 root  _sndiop   52,   2 Jul 27 10:16 /dev/rmidi2
crw-rw  1 root  _sndiop   52,   3 Jul 27 10:16 /dev/rmidi3
crw-rw  1 root  _sndiop   52,   4 Jul 27 10:16 /dev/rmidi4
crw-rw  1 root  _sndiop   52,   5 Jul 27 10:16 /dev/rmidi5
crw-rw  1 root  _sndiop   52,   6 Jul 27 10:16 /dev/rmidi6
crw-rw  1 root  _sndiop   52,   7 Jul 27 10:16 /dev/rmidi7

Re: writing aucat output

[Alexandre Ratchov]

On Fri, Jun 05, 2020 at 12:06:54PM +0200, Peter J. Philipp wrote:
> Hi,
> 
> I'm wondering how I can write to stdout on aucat?  Here is what I have:
> 
> beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o - | hexdump -C
> stdout: failed to seek back to header
> beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o /dev/stdout | hexdump -
> /dev/stdout: failed to seek back to header
> 
> It doesn't seem to work for me.  I'm a little distracted too.  Anyone want
> to lift me on their shoulders?
> 
> My intention is to resample input audio to 44100 and output it to a wav.

Hi,

I think you need:

aucat -n -i ewhist2.wav -r 44100 -o ewhist2_44100.wav

If you need to pipe the result to another program, use the raw format, example:

aucat -n -i fanza_mix_ter.wav -r 44100 -o - | lame -r -s 44.1 - ewhist2.mp3

Last point, I'd suggest using audio/sox port to resample files, you'll
get much better quality, example:

sox ewhist2.wav -r 44100 ewhist2_44100.wav

Re: Distorted sound in 6.7

[Alexandre Ratchov]

On Fri, May 22, 2020 at 12:35:06PM +0100, Maurice McCarthy wrote:
> Hi,
> 
> Since installing 6.7 I've found that human voices in mpv or youtube
> sound either very quiet or  as-if  "under water" or bubbly. I was
> unable to cure this with sndioctl but succeeded with the old mixerctl
> 
> doas outputs.master=200,150
> 

Most probably the speaker(s) are not properly wired and left and right
channels cancel each other. You could check this as follows: play a
mono file and meanwhile try the following:

doas outputs.master=200,0
doas outputs.master=0,200
doas outputs.master=200,200

first two should play but the last one should produce (almost)
silence.

> If I understand sndioctl well enough this kind of left and right
> speaker adjustment is not possible under sndioctl. dmesg attached.
> 

fwiw, to control individual channels (if hardware allows it), put the
channel number between squire brackets:

sndioctl output[1].level=0

> Thanks again for all the magnificent effort. I've made a donation
> within my means.
> 

thank you

Re: Multimedia FAQ

[Alexandre Ratchov]

On Thu, May 07, 2020 at 06:12:21PM -0300, Oficial wrote:
> Hi,
> 
> The multimedia FAQ (https://www.openbsd.org/faq/faq13.html), list some
> mixerctl outputs like:
> 
>  outputs.headphones=160,160
>  outputs.headphones.mute=off
> 
> In my system (current i386) there is no "outputs.headphones.mute" for
> example, but there is a "outputs.hp_mute".

Hi,

Each sound-card model has its own specific set of controls, yours is
different from the one of the example.

> The documentation is outdated ?
> 

The audio parts needs *many* updates after the recent audio changes,
we're working on it.

Re: Sound is good on OpenBSD

[Alexandre Ratchov]

On Wed, Apr 29, 2020 at 11:46:06AM +0200, Moises Simon wrote:
> On Tue, Apr 28, 2020 at 03:38:58PM -0500, Abel Abraham Camarillo Ojeda wrote:
> > I think increasing -b option in sndiod helps to prevent audio jumping, I
> > hear music with a local mpd with music directory over nfs, plus a lot of
> > firefox and chrome and hear no jumps , etc
> > 
> > regards
> 
> I can confirm. For me setting -b 8640 stops the audio jumping.
> 
> Thanks Abel.
> 

what devices are you using? azalia? usb?

Re: couldn't find audio device

[Alexandre Ratchov]

On Fri, Apr 24, 2020 at 09:43:12AM +0200, Damien Thiriet wrote:
> Hi misc@,
> 
> 
> I am trying to make audio records from my web cam but
> cannot succeed in doing it.
> I read the FAQ, aucat(1), audioctl(1) and sndiod(8) man pages (but I 
> certainly misunderstood them) and searched the mailing list. 
> I think they are obvious things I simply don't understand, any help 
> welcome.
> 
> Looks like my webcam is recognized by the system
> 
> $ dmesg|grep audio
> audio0 at azalia1
> uaudio0 at uhub0 port 3 configuration 1 interface 3 "Logitech product 0x0808" 
> rev 2.00/0.09 addr 2
> uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls
> audio1 at uaudio0
> 
> I switched recording on, as advised in the FAQ
> $ /usr/bin/doas /usr/sbin/sysctl kern.audio.record=1
> kern.audio.record: 1 -> 1
> 
> $ aucat -f /dev/audio1 -o test.wav
> /dev/audio1: couldn't open audio device
> 
> $ audioctl -f /dev/audio1
> audioctl: /dev/audio1: Device not configured
> 
> I understand I should use sndiod, but doing
> # sndiod -f /dev/audio1
> did not help, even after
> # rcctl restart sndiod
> 
> What did I miss? My user is member of wheel, I understand he should have
> access to /dev/audio1
> 

You don't need special privileges to use audio, you only need to
enable the device in sndiod. To use both of your devices (internal and
USB), you could run:

rcctl set sndiod flags -f rsnd/0 -f rsnd/1
rcctl restart sndiod

At this point you could run:

aucat -f snd/1 -o test.wav

and /tmp/foo.wav

Note that this device is not full-duplex, it is suitable for recording
but not for telephony in web browsers.

-- Alexandre

Re: Using a C310 Logitech webcam mic with internal speakers

[Alexandre Ratchov]

On Thu, Apr 23, 2020 at 10:01:52AM -0400, Jon Fineman wrote:
> On 2020-04-23 08:40, Alexandre Ratchov wrote:
> > On Wed, Apr 22, 2020 at 02:17:35PM +, Jon Fineman wrote:
> > > 
> > > Is there a way to set the mic to one channel and the speakers to
> > > another? Or merge the speakers from channel rsnd/0 and rsnd/1
> > > together and have them output on rsnd/0?
> > 
> > Sorry, two devices can't be combined into a single one on OpenBSD.
> > 
> 
> What started me down this path was that I can't get chromium or firefox to
> recognize the webcam if it is using rsnd/1. Changing it to rsnd/0 allowed
> the browsers to see it.
> 
> Am I doing something wrong with configuring things? I am on 6.7
> GENERIC.MP#128 amd64.
> 
> If the browser recognizes the webcam on rsnd/1 I could then get a combo
> headphone and mic and plug that into rsnd/0, assuming the browser will
> recognize the audio on rsnd/0.
> 

The c310 has two devices inside a webcam and a usb microphone.

The webcam is a video(4) device and can be used for video capture no
matter if the microphone is used or not. For video(4) devices to work,
/dev/video0 permissions need to be adjusted.

Currently browsers need a full-duplex audio device for telephony
web-sites, so the webcam microphone won't work for them, sorry.

Note that the "rsnd/N" you're refering to were disabled to regular
users recently, but that's not related your problem.

Re: Using a C310 Logitech webcam mic with internal speakers

[Alexandre Ratchov]

On Wed, Apr 22, 2020 at 02:17:35PM +, Jon Fineman wrote:
>
> Is there a way to set the mic to one channel and the speakers to
> another? Or merge the speakers from channel rsnd/0 and rsnd/1
> together and have them output on rsnd/0?

Sorry, two devices can't be combined into a single one on OpenBSD.

Re: sndioctl double behaviour

[Alexandre Ratchov]

On Tue, Apr 21, 2020 at 09:38:04AM -0600, Theo de Raadt wrote:
> Looks broken.
> 
> Mihai Popescu  wrote:
> 
> > Hi,
> > 
> > It's clear OpenBSD is moving to sndioctl. I used it, but I got some
> > "strange" behaviour.
> > Watching youtube in chromium, tried this:
> > 
> > $ sndioctl output.level=1
> > default: can't open control device
> > 
> > After closing / restarting chromium, and starting youtube I can run same
> > command many times:
> > 
> > $ sndioctl output.level=1
> > output.level=1
> > $ sndioctl output.level=0
> > output.level=0
> > $ sndioctl output.level=1
> > output.level=1
> > 
> > Expected?
> 

It looks like caused by unveil(2) usage in chrome. According to
unveil(2):

 Directories are remembered at the time of a call to unveil().
 This means that a directory that is removed and recreated after a
 call to unveil() will appear to not exist.

so, unveil("~/.sndio") is called, if chrome is the first program to
use audio, the directory doesn't exist so it's not unveiled. Then,
chrome connects to sndiod, creates "~/.sndio" directory and tries to
save the cookie, which fails. Then, other programs (like sndioctl)
will be rejected by sndiod until chrome disconnects.

Adding the full cookie path wouldn't help as the directory doesn't
exist yet.

Hmm.

Re: sndioctl double behaviour

[Alexandre Ratchov]

On Tue, Apr 21, 2020 at 06:13:42PM +0300, Mihai Popescu wrote:
> Hi,
> 
> It's clear OpenBSD is moving to sndioctl. I used it, but I got some
> "strange" behaviour.
> Watching youtube in chromium, tried this:
> 
> $ sndioctl output.level=1
> default: can't open control device
> 
> After closing / restarting chromium, and starting youtube I can run same
> command many times:
> 
> $ sndioctl output.level=1
> output.level=1
> $ sndioctl output.level=0
> output.level=0
> $ sndioctl output.level=1
> output.level=1
> 
> Expected?

No, thanks for reporting this. Any hints how to easily reproduce?

Re: sndioctl and USB HID keyboard

[Alexandre Ratchov]

On Tue, Apr 21, 2020 at 03:15:58AM +0200, Erling Westenvik wrote:
> > > 
> > > I'm a bit confused now... so why the previous usbhidaction configuration
> > > (which was aligned to the manpage suggestions and worked flawlessly for
> > > years) doesn't work anymore?
> > 
> > Sorry, few weeks ago mixerctl was changed to use /dev/audioctlN
> > instead of /dev/mixerN (which was just removed), but the
> > usbhidaction(1) man page was not updated. Now it's fixed.
> > 
> > The sample invocation line should read:
> > 
> > usbhidaction -f /dev/uhid1 -c conf /dev/audioctl0
> > 
> > Tested on my setup, let me know if it works for you.
> 
> I'm puzzled. This is -current as of yesterday (April 20th).
> 
> From /etc/rc.conf.local:
>   usbhidaction_flags=-f /dev/uhid0 -c /etc/usbhidaction.conf 
> /dev/audioctl0
> 
> My /etc/usbhidaction.conf:
>   Consumer:Play/Pause 1
>   echo 'cycle pause' | socat - /tmp/mpvsocket
>   Consumer:Volume_Decrement 1
>   sndioctl output.level=-0.1
>   #mixerctl outputs.master=-8
>   Consumer:Volume_Increment 1
>   sndioctl output.level=+0.1
>   #mixerctl outputs.master=+8
>   Consumer:Mute 1
>   sndioctl output.mute=!
>   #mixerctl outputs.master.mute=toggle
> 
> But alas, nothing happens when I press the respective buttons on my
> keyboard. 
> Running from command line works, but not as root/doas..
> 
> Running with doas: $ doas sndioctl output.level=+0.1
>   default: can't open control device
> 
> Running as myself: $ sndioctl output.level=+0.1
>   output.level=0.6
> 

Hi,

mixerctl is still the appropriate tool here, sndioctl is not inteded
to be run as root.

usbhidaction runs as root, given /dev/uhidN permissions, it's clearly
not intended to run "high level" user commands.  For instance it makes
no sense to run "audiocious -u" when Pause/Play key is hit, it's the
similar for sndioctl. The mixerctl utility remains for such "low
level" use cases.

Any program using sndiod is intended to be used one user at a time for
obvious privacy reasons, this is quickly explained in the last
section of sndio(7).

Re: sndioctl and USB HID keyboard

[Alexandre Ratchov]

On Mon, Apr 20, 2020 at 08:00:05PM +0200, Alessandro De Laurenzis wrote:
> Hello Alexandre,
> 
> On 20/04/2020 - 19:50, Alexandre Ratchov wrote:
> > On Mon, Apr 20, 2020 at 07:35:03PM +0200, Alessandro De Laurenzis wrote:
> > > Hello Alexandre,
> > > 
> > > Thanks for your prompt feedback.
> > > 
> > > On 20/04/2020 - 18:00, Alexandre Ratchov wrote:
> > > [...]
> > > >
> > > > This is the right way of doing it except that the user-id running
> > > > sndioctl is probably not authorized to use the server while you're
> > > > using.
> > > >
> > > > You could try to prefix the command with "doas -u "
> > > >
> > > > -- Alexandre
> > > >
> > > 
> > > Yes, that's the root cause and prefixing the sndioctl command with doas
> > > makes the trick. Unfortunately, this solution isn't applicable to my
> > > use-case, since there are several users that can log in this machine...
> > > 
> > > Are there any alternatives?
> > 
> > mixerctl still works for root.
> > 
> 
> I'm a bit confused now... so why the previous usbhidaction configuration
> (which was aligned to the manpage suggestions and worked flawlessly for
> years) doesn't work anymore?

Sorry, few weeks ago mixerctl was changed to use /dev/audioctlN
instead of /dev/mixerN (which was just removed), but the
usbhidaction(1) man page was not updated. Now it's fixed.

The sample invocation line should read:

usbhidaction -f /dev/uhid1 -c conf /dev/audioctl0

Tested on my setup, let me know if it works for you.

Re: sndioctl and USB HID keyboard

[Alexandre Ratchov]

On Mon, Apr 20, 2020 at 07:35:03PM +0200, Alessandro De Laurenzis wrote:
> Hello Alexandre,
> 
> Thanks for your prompt feedback.
> 
> On 20/04/2020 - 18:00, Alexandre Ratchov wrote:
> [...]
> > 
> > This is the right way of doing it except that the user-id running
> > sndioctl is probably not authorized to use the server while you're
> > using.
> > 
> > You could try to prefix the command with "doas -u "
> > 
> > -- Alexandre
> > 
> 
> Yes, that's the root cause and prefixing the sndioctl command with doas
> makes the trick. Unfortunately, this solution isn't applicable to my
> use-case, since there are several users that can log in this machine...
> 
> Are there any alternatives?

mixerctl still works for root.

Re: sndioctl and USB HID keyboard

[Alexandre Ratchov]

On Mon, Apr 20, 2020 at 05:07:26PM +0200, Alessandro De Laurenzis wrote:
> Greetings,
> 
> Latest -current here:
> 
> OpenBSD theseus.atlantide.priv 6.7 GENERIC.MP#140 amd64
> 
> Of course, mixerctl doesn't work anymore for volume control.
> 
> I have a Logitech wireless keyboard whose multimedia keys were pretty
> functional in OpenBSD through usbhidaction(1):
> 
> [...]
> Apr 20 16:54:48 theseus /bsd: uhidev0 at uhub0 port 2 configuration 1 
> interface 0 "Logitech USB Receiver" rev 2.00/12.01 addr 2
> Apr 20 16:54:48 theseus /bsd: uhidev0: iclass 3/1
> Apr 20 16:54:48 theseus /bsd: ukbd0 at uhidev0: 8 variable keys, 6 key codes
> Apr 20 16:54:48 theseus /bsd: wskbd1 at ukbd0 mux 1
> Apr 20 16:54:48 theseus /bsd: wskbd1: connecting to wsdisplay0
> Apr 20 16:54:48 theseus /bsd: uhidev1 at uhub0 port 2 configuration 1 
> interface 1 "Logitech USB Receiver" rev 2.00/12.01 addr 2
> Apr 20 16:54:48 theseus /bsd: uhidev1: iclass 3/1, 8 report ids
> Apr 20 16:54:48 theseus /bsd: ums0 at uhidev1 reportid 2: 16 buttons, Z and W 
> dir
> Apr 20 16:54:48 theseus /bsd: wsmouse2 at ums0 mux 0
> Apr 20 16:54:48 theseus /bsd: uhid0 at uhidev1 reportid 3: input=4, output=0, 
> feature=0
> Apr 20 16:54:48 theseus /bsd: uhid1 at uhidev1 reportid 4: input=1, output=0, 
> feature=0
> Apr 20 16:54:48 theseus /bsd: uhid2 at uhidev1 reportid 8: input=1, output=0, 
> feature=0
> Apr 20 16:54:48 theseus /bsd: uhidev2 at uhub0 port 2 configuration 1 
> interface 2 "Logitech USB Receiver" rev 2.00/12.01 addr 2
> Apr 20 16:54:48 theseus /bsd: uhidev2: iclass 3/0, 33 report ids
> Apr 20 16:54:48 theseus /bsd: uhid3 at uhidev2 reportid 16: input=6, 
> output=6, feature=0
> Apr 20 16:54:48 theseus /bsd: uhid4 at uhidev2 reportid 17: input=19, 
> output=19, feature=0
> Apr 20 16:54:48 theseus /bsd: uhid5 at uhidev2 reportid 32: input=14, 
> output=14, feature=0
> Apr 20 16:54:48 theseus /bsd: uhid6 at uhidev2 reportid 33: input=31, 
> output=31, feature=0
> [...]
> 
> This is the command that I use through hotplugd (adapted from the manpage,
> which is BTW now outdated, and modified to cope with sndioctl):
> 
> [...]
> usbhidaction -f /dev/uhid0 -c /etc/usbhidaction/vol-ctrl
> [...]
> 
> and this is the content of /etc/usbhidaction/vol-ctrl
> 
> [...]
> # The volume range is 0..1. Moving 0.1 volume steps each keypress
> # moves quickly through the volume range but still has decent
> # granularity.
> Consumer:Bass 1
> sndioctl output.mute=!
> Consumer:0x00eb 1
> sndioctl output.level=-0.1
> Consumer:Volume_Decrement 1
> sndioctl output.level=+0.1
> [...]
> 
> but when I use the multimedia keys... nothing happens. I really don't know
> how to debug this; is it related to the interaction with sndio?
> 
> Any hints?
> 

This is the right way of doing it except that the user-id running
sndioctl is probably not authorized to use the server while you're
using.

You could try to prefix the command with "doas -u "

-- Alexandre

Re: Problem with mixerctl on latest snapshot

[Alexandre Ratchov]

On Sun, Apr 19, 2020 at 09:11:16AM +0200, zeurk...@volny.cz wrote:
> 
> > Now programs connect to sndiod which does the hardware access for
> > them, this has other advantages as well:
> > - programs control the volume of the right device on systems with
> >  multiple audio devices (ex. usb head sets)
> > - there's always a volume control, even if the hardware lacks one, as
> >  may usb devices.
> > - unified view of hardware and software controls, network
> >  transparency, etc
> 
> That may all be, but like xenodm(1), memight find (future tense, as me's
> not running -current or snapshots) the above proposed solution
> inadequate for me needs.

Hi,

I'm curious, what use-case is not handled and still requires access to
the device nodes?

Re: Problem with mixerctl on latest snapshot

[Alexandre Ratchov]

On Sat, Apr 18, 2020 at 03:53:19PM -0700, Renato Aguiar wrote:
> Hi,
> 
> After updating to latest snapshot, mixerctl stopped working with non-root
> user:
> 
>$ mixerctl
>mixerctl: /dev/audioctl0: Permission denied
>$ ls -l /dev/audioctl0
>crw-rw  1 root  _sndiop   42, 192 Apr 18 14:29/dev/audioctl0
>$
> 

Hi,

You could use the sndioctl utility to adjust the volume, it's similar
to mixerctl.

Access to audio and MIDI related device nodes is now disabled for
security reasons. We don't want programs we run, possibly processing
untrusted input, to be allowed to directly access low level drivers
and attempt to exploit kernel bugs.

Now programs connect to sndiod which does the hardware access for
them, this has other advantages as well:
- programs control the volume of the right device on systems with
  multiple audio devices (ex. usb head sets)
- there's always a volume control, even if the hardware lacks one, as
  may usb devices.
- unified view of hardware and software controls, network
  transparency, etc

mixerctl remains as a configuration tool, /etc/mixerctl.conf is still
processed on system startup.

Re: Record with a device, playback with another with sndiod

[Alexandre Ratchov]

On Sat, Mar 14, 2020 at 09:10:19AM +0100, David Demelier wrote:
> Hello,
> 
> I'm trying to setup sndiod to record input using my laptop's builtin
> microphone but using an USB sound card for output.
> 
> The microphone does work correctly because I was able to record some
> test using aucat
> 
> $ aucat -o test.wav
> $ aucat -i test.wav (worked)
> 
> To my understanding the option -m can be used to control either both
> playback and recording so I've tried to setup my rsnd/0 (laptop) to only
> use recording and my external dock rsnd/1 to only use playback.
> 
> $ sndiod -f rsnd/1 -s default -m play -F rsnd/1 -f rsnd/0 -m rec
> 
> The playback works correctly on the USB dock but plain `aucat -o` won't
> record from the laptop's microphone. However, `aucat -f rsnd/0 -o
> test.wav` works but since Firefox won't let me choose a specific input
> device I'm stuck...
> 
> Do I miss something or it's simply not possible to create this "virtual"
> unique device that consist of input from a card and output to another
> one?

Hi,

Sorry, it's not possible to combine two devices into a single one with
sndiod.

FWIW, this is because both devices don't use the same clock source, if
there were combined, audio could be unstable. Properly synchronizing
them is difficult and given the price and availability of full-duplex
hardware it is not worth the risk of making audio unreliable.

I guess you're asking because the USB dock has no microphone, right?

Re: Jitsi on OpenBSD

[Alexandre Ratchov]

On Mon, Mar 16, 2020 at 10:59:08AM +, Edd Barrett wrote:
> Hi,
> 
> (CC people who may be knowledgable in this area)
> 
> I was wondering if anyone has got the Jitsi (https://jitsi.org/)
> web-client working on OpenBSD?
> 
> It's open-source (and self-hostable) video conferencing.
> 
> No prizes for guessing why I'm investigating this :P
> 
> I've just (quickly) tried the browser client in firefox:
> 
>  - It recognises my microphone and my camera.
>  - Thumbnail shows local video feed OK.
>  - I can hear audio from an android participant.
>  - The android participant cannot hear the audio from the OpenBSD machine.
>  - The video is super-flaky on both ends.
> 
> Did this, as per firefox README:
> 
>  - I have sysctl kern.audio.record=1.
>  - I chowned /dev/video0 to me.
> 
> This evening I'm going to have a deeper play around (e.g. verify if mic
> works in aucat), but if anyone has got this working before, I'd love to
> hear what tweaks they had to do.
> 
> Could be that the jitsi server is overloaded.

Hi,

I haven't used jitsi yet, but other video-converencing web sites
properly work in firefox. Jitsi claim they support chrome only, but
according to the settings window's microphone level meter, it's
properly recording.

There was a recent regression in firefox 73., so check that you're
using version 74 before testing.

HTH,

-- Alexandre