Audio initialization/deinitialization moved directly before/after the pl...

[ghost]

...ayback start/stop.

Previously audio was initialized directly after application startup what caused issues with resampling in pulseaudio (all other pulseaudio clients were being resampled to 44kHz if they had higher sample rate)

[abrasive]

NAK.

At the moment, audio init is performed upfront so that errors can be detected on startup, as far as is possible. The alternative is having shairport fall over when someone hits play, which is a bad user experience.

The first target for this sort of issue is the PA config. Doesn't PA upsample to the engine default rate?

The Pulse backend would also be a good place to work on this. It's not clear to me whether the asynch API allows server connection to be separated more cleanly from streaming activity. Certainly the connection to the server should be tested at startup, even if by playing some zero samples and then closing up if that's what it takes.

(Your patch is incomplete, by the way; newArgv and newArgc are never set).

[ghost]

Hi, thanks for the reply.
In PA config one can specify the default and the alternative sampling frequency. It's good idea to make that alternative equals your sound card max samp freq. If you then play a stream having either default or alternative sampling rate, there will be no conversion at all. When you play stream with FS>alternative, it will be downsampled to the alternative fs. However it gets more messy when there are couple of streams (clients) connected to PA.
When there is more then one stream, they all get downsampled to the fs=min(f1,f2,f3..), where f- sample rates of particular streams. This is described in PA doc and it's a proper, understandable behaviour.
So the problem is that when the shairport is always connected to the PA and visible as a "sink input" and it has 44kHz sampling, it forces PA to downsample all the other clients to 44kHz. So even though my sound card can handle 96kHz, my flac files playd by lets say MPD will be downsampled. It causes both unnecesary CPU load (high for tiny machines) and quality downgrade.

I agree that the connection should be checked at startup to detect configuration issues, I will add it. And it my previous commit I forgot one file, that's why my patch was not complete ;)

On Feb 3, 2014, at 1:37 AM, James Laird [email protected] wrote:

NAK.

At the moment, audio init is performed upfront so that errors can be detected on startup, as far as is possible. The alternative is having shairport fall over when someone hits play, which is a bad user experience.

The first target for this sort of issue is the PA config. Doesn't PA upsample to the engine default rate?

The Pulse backend would also be a good place to work on this. It's not clear to me whether the asynch API allows server connection to be separated more cleanly from streaming activity. Certainly the connection to the server should be tested at startup, even if by playing some zero samples and then closing up if that's what it takes.

(Your patch is incomplete, by the way; newArgv and newArgc are never set).

—
Reply to this email directly or view it on GitHub.