OpenBSD 7.1: sndio klemmt. Wo kann ich nachgucken?

dettus

Bicycle User
Hallo.

Manchmal habe ich das Problem, dass mir Firefox die Audio-Ausgabe kaputt macht.


Wenn ich mit mplayer ein .mp3 abspielen moechte, dann sehe ich nur das hier:
Code:
libavformat version 58.76.100 (external)
Audio only file format detected.
Load subtitles in ./
==========================================================================
Requested audio codec family [mpg123] (afm=mpg123) not available.
Enable it at compilation.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
libavcodec version 58.134.100 (external)
AUDIO: 44100 Hz, 2 ch, floatle, 256.0 kbit/9.07% (ratio: 32000->352800)
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
==========================================================================
AO: [sndio] 44100Hz 2ch s32le (4 bytes per sample)
Video: no video
Starting playback...
A:  -0.0 (unknown) of 174.0 (02:54.0) ??,?%




Natuerlich hoere ich nix.

Soweit ich das beurteilen kann sieht eigentlich alles okay aus:
Code:
# audioctl
name=azalia1
mode=
pause=0
active=0
nblks=16
blksz=480
rate=48000
encoding=s16le
play.channels=2
play.bytes=0
play.errors=0
record.channels=2
record.bytes=0
record.errors=0

# ls -l /dev/audio*
crw-rw----  1 root  _sndiop   42,   0 Jul 24 00:46 /dev/audio0
crw-rw----  1 root  _sndiop   42,   1 Jul  1 17:25 /dev/audio1
crw-rw----  1 root  _sndiop   42,   2 Jul  1 17:25 /dev/audio2
crw-rw----  1 root  _sndiop   42,   3 Jul  1 17:25 /dev/audio3
crw-rw----  1 root  _sndiop   42, 192 Jul  1 17:25 /dev/audioctl0
crw-rw----  1 root  _sndiop   42, 193 Jul  1 17:25 /dev/audioctl1
crw-rw----  1 root  _sndiop   42, 194 Jul  1 17:25 /dev/audioctl2
crw-rw----  1 root  _sndiop   42, 195 Jul  1 17:25 /dev/audioctl3


# ps auxww | grep -i sndio
_sndiop  95424  0.0  0.0  2652  1096 ??  IpU    12:45AM    0:00.00 sndiod: helper (sndiod)
_sndio   44117  0.0  0.0  2812  1712 ??  I<pc   12:45AM    0:00.01 /usr/bin/sndiod


Ein pkill sndiod ; /usr/bin/sndiod hat natuerlich auch nichts gebracht.
Das einzige, was momentan zu helfen scheint ist ein NEUSTART.

Weiss irgendwer von euch einen besseren Weg?
 
Leider nein ... bislang hatte ich unter OpenBSD wenig bis gar keine Soundprobleme.

Passiert das nur beim Firefox? Du könntest mal Chromium ggf. probieren, Firefox hat zwar die letzten 2,3 Jahre qualitativ enorm zugelegt, aber Chrome hat bei mir immer wieder was "weniger merkwürdige merkwürdigkeiten" angeht weiterhin die nase vorn
 
Nein, nicht nur.
Ich habe auch gerade ein paar Audio-Ausgabeexperimente am laufen.
Mit Firefox ist aber die Wahrscheinlichkeit, dass es klemmt, am groessten.


Bei einem von denen war auch auf einmal Stille...
ICH VERMUTE, dass da irgendwo ein unaligned write war, also einmal wurde statt einem ganzen Sample nur ein Byte geschrieben oder sowas....

Was ich beim naechsten mal probieren werde ist, ob ich mit
Code:
cat /dev/urandom >/dev/audio0
noch was hoere oder ob da was im Kernel klemmt.
 
Hast Du OpenBSD 7.1 frisch installiert? Es gab ein sndio syntax change bei 7.1. Nicht, dass beim upgrade irgendwas schief gelaufen ist.

Configuration and syntax changes​


  • sndio(7). The descriptor format has changed.
    If you explicitly pass audio device descriptors to programs (through program options or through the AUDIODEVICE environment variable), then the descriptors might need to be updated as follows. Otherwise, skip this section.
    Audio devices exposed by sndiod(8) are not bound to physical audio devices anymore, so the physical audio device number component of sndio(7) descriptors was removed. For instance, if the server is started with:
    # sndiod -f rsnd/0 -s foo -f rsnd/1 -s bar
    then programs will need to use "snd/foo" and "snd/bar" (instead of "snd/0.foo" and "snd/1.bar").
    By default programs will try to use "snd/default" (instead of "snd/0"). Unless -s default option is used, "snd/default" is automatically created and attached to the first physical audio device specified on the command line (i.e. first -f or -F option). If needed, this setting may be changed at run-time with the server.device control exposed by sndioctl(1).
    For each physical device managed by the server (i.e. each -f or -F option) the server also exposes a "snd/<number>" descriptor bound to the physical device of the same number. Consequently, "snd/0", "snd/1", ... still can be used to refer to specific physical devices.
 
Du bist als user eingeloggt? Hast du ein .sndio/cookie in deinem $HOME? Hast Du noch andere audio daemons unter anderen usern am laufen?

sndiod(8) normally only allows access to audio by a single system user
at a time. This is done by generating a random authentication token and
storing it in $HOME/.sndio/cookie when a user first accesses audio,
providing a limited capability to share with other users by copying
the token to their home directory. See AUTHENTICATION in sndio(7) for
more details.
 
Das meinte ich mit daemons am Beispiel von z.B. mpd:

If you want to share sndiod(8) access with mpd(1) running as the
default _mpd user, you may copy .sndio/cookie from your user's home
directory to /var/spool/mpd/.sndio/cookie.

Disable einfach mal alle daemons in der rc.conf.local, reboote und schaue, ob die Audioausgabe dann funktioniert. Dann startest Du nach und nach die daemons und guckst, ab welchem Punkt es nicht mehr funktioniert. Was anderes faellt mir sonst auch nicht mehr ein. dbus laeuft aber, oder? :-)
 
Okay... DEFINITIV ein Problem im Kernel.

Code:
# cat audiodump.wav >/dev/audio0

Liefert mir nur rythmisches Rauschen. Da geht irgendwas GEWALTIG schief.

Code:
# dmesg | grep audio
audio0 at azalia1
audio0 at azalia1
audio0 at azalia1

# dmesg | grep azalia
azalia0 at pci7 dev 0 function 1 vendor "NVIDIA", unknown product 0x0e0f rev 0xa1: msi
azalia0: no supported codecs
azalia1 at pci9 dev 0 function 4 "AMD 17h HD Audio" rev 0x00: msi
azalia1: codecs: Realtek ALC1200
audio0 at azalia1
azalia0 at pci7 dev 0 function 1 vendor "NVIDIA", unknown product 0x0e0f rev 0xa1: msi
azalia0: no supported codecs
azalia1 at pci9 dev 0 function 4 "AMD 17h HD Audio" rev 0x00: msi
azalia1: codecs: Realtek ALC1200
audio0 at azalia1
azalia0 at pci7 dev 0 function 1 vendor "NVIDIA", unknown product 0x0e0f rev 0xa1: msi
azalia0: no supported codecs
azalia1 at pci9 dev 0 function 4 "AMD 17h HD Audio" rev 0x00: msi
azalia1: codecs: Realtek ALC1200
audio0 at azalia1

Wie gesagt: Nach einem Reboot funktioniert es wieder.
 
So. Meine Zwischenloesung: Ich habe mir fuer 10 Euro einen Speedlink Audio Device gekauft.
Code:
# dmesg | grep audio
audio0 at azalia1
audio0 at azalia1
uaudio0 at uhub3 port 4 configuration 1 interface 1 "EasyDisk USB PnP Audio Device" rev 1.10/1.00 addr 2
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 5 ctls
audio1 at uaudio0
audio1 detached
uaudio0 detached
uaudio0 at uhub3 port 4 configuration 1 interface 1 "EasyDisk USB PnP Audio Device" rev 1.10/1.00 addr 2
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 5 ctls
audio1 at uaudio0
audio0 at azalia1
uaudio0 at uhub2 port 4 configuration 1 interface 1 "EasyDisk USB PnP Audio Device" rev 1.10/1.00 addr 4
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 5 ctls
audio1 at uaudio0
uaudio0: play xfer, err = 6
audio1 detached
uaudio0 detached
uaudio0 at uhub0 port 13 configuration 1 interface 1 "EasyDisk USB PnP Audio Device" rev 1.10/1.00 addr 4
uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 5 ctls
audio1 at uaudio0
# usbdevs
Controller /dev/usb0:
addr 01: 1022:0000 AMD, xHCI root hub
addr 02: 0b05:1939 AsusTek Computer Inc., AURA LED Controller
addr 03: 174c:2074 ASUS TEK., ASM107x
addr 04: 0c76:161f EasyDisk, USB PnP Audio Device
Controller /dev/usb1:
addr 01: 1022:0000 AMD, xHCI root hub


Anschliessend habe ich das neue Audiodevice als default device von sndiod eingerichtet.
Code:
# cat /etc/rc.conf.local
# sndiod_flags=-f rsnd/0 -F rsnd/1
sndiod_flags=-f rsnd/1 -F rsnd/1
xenodm_flags=
# rcctl restart sndiod ; rcctl reload sndiod
sndiod(ok)
sndiod(ok)
sndiod(ok)
 
Zurück
Oben