Re: Apparent sndio issue with underruns on OpenBSD?

On Sun, Feb 23, 2020 at 11:17:15AM +0000, Mike Brady wrote:
> Hi there. I'm the principal developer of Shairport Sync, an Apple
> AirPlay 1 "server" -- a program that accepts audio from a "client"
> such as iTunes and directs it to an audio output. It runs on OpenBSD
> and FreeBSD using the sndio system using a "backend" that takes
> commands and audio from Shairport Sync and directs them to the sndio
> subsystem. (It also runs on Linux using ALSA and others).
> 
> I am writing because while Shairport Sync works well on FreeBSD it
> is crashing on OpenBSD (please see
> https://github.com/mikebrady/shairport-sync/issues/975). I'm testing
> on an installation of OpenBSD 6.6 in a VMWare Fusion VM on an
> iMac. AFAIK all the software is up to date with patches, etc. The
> installation procedure I'm following is at
> https://github.com/mikebrady/shairport-sync/blob/master/OPENBSD.md.
> 

Thanks, I'll look more in depth in the github discussion.

I don't know what audio device VMware emulates (probably eap), but
there were many reports about broken audio in virtual machines. It
seems that there are subtle play/rec synchronization differences
between the real hardware and the emulated one which tend to break
sndiod.

If you don't care about recording, you could try to run the sndiod of
the OpenBSD VM with the '-m play' option and see if problems are gone.
For instance, run as root:

	rcctl set sndiod flags -m play
	rcctl restart sndiod

Another option would be to use a remote soundcard instead of the one
of the OpenBSD VM. For instance, add the '-L -' sndiod option to the
working system, then run the client on the OpenBSD system with the
following environment variable set:

	AUDIODEVICE=snd_at_<ip_addr>/0

where <ip_addr> is the IP address of the working system. This way you
could test on OpenBSD without using the emulated hardware.

Let me know if this works.

> If I start shairport-sync and play a track from, say, the Music app
> on the iMac, everything is fine until I switch tracks. It seems
> (this is me guessing) that underruns occur and that they cause the
> sndio system to stop responding for about four seconds and then
> enter an error state, returning an error code of 1 for
> everything. When I changed the xrun behaviour to SIO_ERROR the
> program would immediately terminate on those occasions. I wonder if
> you might be able to offer any suggestions.

This happens when there's a hardware anomaly detected, here when the
driver doesn't process an audio block for more than 4 seconds. When
this occurs, sndiod closes the device and disconnects all clients,
hence the errors in the programs.

HTH,

-- Alexandre