Re: Running sndiod as user sndiod on Arch Linux

On Mon, Sep 18, 2017 at 11:32:16AM +0000, Edward Wandasiewicz wrote:
> Brilliant! Thanks for making it crystal clear.
> 
> Reading https://bbs.archlinux.org/viewtopic.php?id=191669
> 
> looks like, on Arch...
> 
> If you have a choice then use Type=simple for your systemd services.
> It is simpler and systemd will take care or proper process
> deamonizing, restarts and shutdowns.
> 
> Type=forking is for historical services that cannot be run in
> foreground. In this case process itself will take care of its
> deamonizing, but systemd should know the child pid somehow so you need
> to provide PIDFile= option as well.

I'm a systemd newbie, but my understanding is that in "simple" mode,
systemd can't figure out when sndiod has finished initializing and is
ready to accept connections. This is overcame with the "notify" mode,
but it would require additional systemd-specific code in sndiod.

With the "forking" mode, systemd waits until the process goes to the
background which happens when sndiod is fully initialized.

AFAIU, the PIDFile= is not necessary as, according to the doc, systemd
uses cgroups to track the daemon process and to figure out its pid.

> The service file below, works fine on Arch, defaults to User=root if
> no User specified - if I add Type=forking
> 
> $ systemctl restart sndiod.service freezes
> 
> [Unit]
> Description=Lightweight audio & MIDI server part of the OpenBSD project
> After=network.target
> 
> [Service]
> # User=root
> # Type=forking
> Restart=on-abort
> EnvironmentFile=/etc/conf.d/sndiod
> ExecStart=/usr/bin/sndiod -dd $OPTS
> 
> [Install]
> WantedBy=multi-user.target
> 

In "forking" mode you've to remove the -d options, otherwise sndiod
won't fork and systemd would wait forever.

> Question: I'm trying to get video and audio in sync, via aucat, using
> -ao alsa. Can it be done?
> 

This can't work, using pipes just moves audio samples and any timing
information is lost. Mplayer has a sndio backend so it can use sndio
natively provided it's build with sndio support enabled.

> 
> pcm.sndio-raw {
> type file
> slave.pcm null
> 
> format raw
> file "| aucat -f snd/0 -i -"
> }
> 

basically any player works as follows:

 - the player decodes audio data slightly in advance and sends is to
   the audio sub-system, which buffers it. Data is played at constant
   rate with a small delay roughly corresponding to the buffer size.

 - at the same time, the audio sub-system sends feed-back to the
   player about the current audio position (ie which sample Joe hears)
   which is used to figure out which picture to display.

With pipes (which are unidirectional), the feedback is lost and the
player doesn't know when to display pictures. Furthermore this adds
and extra layer, increasing the overhead.