sndiod enable

S

sidetone

I have been wondering about using audio/sndio and sndiod on FreeBSD. So, I found /usr/local/etc/rc.d/sndiod. From here, it should be enabled with service sndiod onestart, and by entering sndiod_enable="YES" in /etc/rc.conf.local. When I didn't have a sound interface, the output from mixer would state so. sndiod hasn't been looked at much, and it would be cool to determine or to select it to be used to play sounds.
 
It wasn't necessarily sndio that was running.

On my fresh ports install, audio/sox wouldn't play sound, when the configuration was set to sndio, while there was that message about no user sound interface when running mixer . On a previous installation where I already had other sound interfaces installed (oss, alsa, pulseaudio, etc...), sox would play with sndio enabled, and other sound interfaces disabled.

oss might have been running the interface. I understand how sndio could have played a part, but I don't see how it could do that on its own, if it's not enabled. This is considering, sndio has an rc enable feature, and other sound interfaces run by being installed without starting an rc service.
 
audio/sndio should work in FreeBSD like ALSA, just to serve to interface with oss.

I remember reading a thread about alsa-firefox and some folks were having volume problems while using audio/sndio with the daemon running. It seem the volume was considerably lower.

If you want to use audio/sndio instead of oss when it is supported by the port, you should fall in the same situation of when using audio/oss (port), which IIRC you need to rebuild the kernel without sound(4).
 
tl;dr Having sndiod_enable=YES set or starting the daemon is not necessary.

So I think there is some confusion here on the forums about how sndio, OSS, ALSA, etc. fit together.

Sndio has a layered architecture, and you can separate it into multiple components:
  1. libsndio provides an API for applications
  2. sndiod provides network transparency, splitting an audio device into multiple sub-devices, application level volume control, synchronized start/stops via MIDI messages, etc.
  3. the native audio device
Here are some of the basic example use cases and a representation of the data flows for each (-> means 'writes to' or 'reads from'):
  1. Use it without having sndiod running
    Code: 
       sox
-> libsndio
-> sound(4)
  2. Using it with a local sndiod running
    Code: 
       sox
-> libsndio (via aucat backend over UNIX socket)
-> sndiod
-> libsndio
-> sound(4)
  3. Play remotely by e.g. setting the AUDIODEVICE environment variable to something like e.g. snd@remotehost/0
    Code: 
       sox
-> libsndio (via aucat backend over TCP/IP)
-> sndiod on remote host
-> libsndio
-> sound(4) or ALSA or audio(4)
    The remote host can be one of the supported systems i.e. FreeBSD, Dragonfly, Linux, or OpenBSD.
You can also chain multiple sndiod instances together if you want to, so this can get way more complicated quickly.

libsndio is smart and has a strict and practical fallback order for sio_open(3), so in the common case there is indeed nothing to configure:
  1. Is the AUDIODEVICE environment variable set? If yes use it to determine where audio should go and skip everything else here.
  2. Do we have a user local daemon running as device 0 unit 0 (i.e. snd/0)?
  3. Do we have a system daemon (i.e. a daemon started through the rc script or simply sndiod as root) running as device 0 unit 0 (i.e. snd/0)?
  4. If nothing of the above applies use /dev/dsp (the default device) directly. Note that this behavior is special to the FreeBSD port. I wanted it to just work in the common case. On Linux and OpenBSD it would fallback to the first device /dev/audio0 instead.
So armed with the information above we can actually start debugging the problem you have with sox. Start a user local sndiod instance as your user with sndiod -dd (add more ds to make it more verbose) then run sox. Audio will go through your sndiod instance, so a message like
Code: 
sox0: 44100Hz, s16le, play 0:1, 19 blocks of 470 frames
should appear in the terminal where sndiod is running when sox connect to the daemon. If necessary you can also set the SNDIO_DEBUG environment variable to 1, 2, ... to increase verbosity of libsndio.

As a side note and only AFAIK, the packages on TrueOS UNSTABLE are all compiled with the SNDIO option turned on (and ALSA, JACK, PULSEAUDIO turned off). So that might be a faster or more convenient way to try it out with larger applications like e.g. Firefox or Chromium without having to recompile them.
 
Can sndio(7) be used to take input from MIDI devices and interface to OSS, or can it be used through sndiod(8)? I hear that FreeBSD's native OSS driver doesn't take MIDI input.

Can sndio related components be used as a /dev/ driver on FreeBSD, like they are on OpenBSD? I wonder if sndiod can work as a replacement for audio/jack.
 
sidetone said:
Can sndio(7) be used to take input from MIDI devices and interface to OSS, or can it be used through sndiod(8)?
Click to expand...
What do you mean by "interface to OSS"? sndio's rmidi/X.Y directly maps to /dev/umidiX.Y, so yes it can take input from MIDI devices. With sndiod you can also export them to the network just like with audio.
sidetone said:
Can sndio related components be used as a /dev/ driver on FreeBSD, like they are on OpenBSD?
Click to expand...
I'm not sure I understand the question. libsndio uses the /dev/dsp* and /dev/umidi* devices on FreeBSD, just like it uses /dev/audio* and /dev/rmidi* on OpenBSD.

It does not create any device nodes in /dev.
 
Using sndiod for cava and musicpd does stop the stuttering. I would love to know why creating a fifo would cause it to stutter though. I tried a fifo with sndiod and it still did it.
 
You must log in or register to reply here.
Back
Top