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

Courtney

On 6/2/23 02:39, Alexandre Ratchov wrote:
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.


Reply via email to