>.. macOS only ever programs CS42L84 to operate at either 48 or 96 kHz, we could only add support for those two sample rates to the Linux driver ..

> However, CS42L42 supports all the other common sample rates, and while the register layout and programming sequence is different, the actual values programmed in for 48 and 96 kHz are the same across both chips. What would happen if we simply took the values for all other sample rates from the CS42L42 datasheet and added those to the CS42L84 driver? As it turns out, you get support for those sample rates!

> The patch to enable hardware support for 44.1, 88.2, 176.4 and 192 kHz sample rates on both the input and output of the headphone jack was submitted directly upstream, and has been merged for 7.1. We also backported this to Asahi kernel 6.19.9, allowing users to take advantage of this immediately.

Nice bit of chip sleuthing and reverse engineering from the Asahi team!

▲

kccqzy an hour ago | parent | next [-]

The following is actually the most surprising part to me.

> This is quite limiting, as it forces PipeWire to waste CPU cycles (and therefore battery life) on resampling audio streams that are not either 48 or 96 kHz.

So the Asahi team thinks that only supporting 48 or 96 kHz wastes battery life by forcing the software to resample audio streams. But why does Apple still do this? Presumably Apple has a very high commitment to save power and increase battery life.

	▲	ryandrake an hour ago \| parent [-]
		Always possible that it's the standard commercial software company reason: They do know about it and have a P2 bug tracking it, but the team that maintains that code has 5000 other things to do, and it never gets fixed.

▲

functionmouse 4 hours ago | parent | prev [-]

whoa, bit perfect CD/flac playback in 44.1, that's a killer feature.

▲

IshKebab 3 hours ago | parent [-]

There are many audio resampling libraries available that can convert from 44.1 to 48 kHz with no perceptible quality loss. E.g. see

https://github.com/hasenbanck/resampler#quality-analysis

This is presumably what Apple does. You kind of have to anyway or you have the stupid situation Linux used to have where only one app could play audio at a time.

▲

chronogram 3 hours ago | parent | next [-]

Hardware often reports supporting 44.1kHz but internally resamples it to 48kHz so you're better off properly resampling it yourself.

▲

embedding-shape an hour ago | parent | prev [-]

> you have the stupid situation Linux used to have where only one app could play audio at a time

When was that? I think my first Linux distribution was Ubuntu 8.04 and fairly sure it shipped with PulseAudio which in mind always been able to play audio from multiple sources at the same time, maybe I misremember?

	▲	Matl 3 minutes ago \| parent \| next [-]
		Pure ALSA would behave like that because the currently playing process would take exclusive control of the hardware. Upsite: Highest quality playback. Downside: Only one process could play audio at a time.
	▲	mixmastamyk 32 minutes ago \| parent \| prev \| next [-]
		Came later I believe. They had esd and other sound “servers” back then however. Might have had to install it yourself.
	▲	skydhash 24 minutes ago \| parent \| prev [-]
		If you have two audio streams, you can't play them as is on the audio device, you have to mix them together. The same happens with analog speakers as you can't just add two signals together. I believe at one point with Alsa, when an application takes control of the audio device, no one else could play with it. Now Alsa comes with dmix (a digital mixer feature) enabled in its default configuration, so two applications may play how they want. And we have PulseAudio, Jack, and Pipewire on top of Alsa to add more features. OpenBSD still present raw audio devices, but they have sndio which provides a more helpful interface for applications including resampling (not the best algorithms there, according to them).