5 ms·

>.. 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,

by brynet 5mo ago

>.. 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!

functionmouse 5mo ago
whoa, bit perfect CD/flac playback in 44.1, that's a killer feature.
- IshKebab 5mo ago
  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 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 5mo ago
    Hardware often reports supporting 44.1kHz but internally resamples it to 48kHz so you're better off properly resampling it yourself.
  - embedding-shape 5mo ago
    > 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?
    - mixmastamyk 5mo ago
      Came later I believe. They had esd and other sound “servers” back then however. Might have had to install it yourself.
    - skydhash 5mo ago
      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).
      - anthk 5mo ago
        Well, good enough it you read the OpenBSD FAQ section on Multimeda for RT throughput and the like.
    - Matl 5mo ago
      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.
      - seba_dos1 5mo ago
        Only if you had no hardware nor software mixing configured, which probably should be considered a misconfiguration of your system.
- rasz 5mo ago
  No its not. You wont be able to hear the difference between 44.1 vs 48.
kccqzy 5mo ago
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 5mo ago
  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.
  - jasomill 5mo ago
    More likely it’s that 48 kHz is a more sensible default, since the majority of non-music digital audio is sampled at 48 kHz, almost anyone who cares about potential audio artifacts introduced by resampling is going to be using an external DAC, and (from an Apple-centric viewpoint) almost anyone concerned about the energy consumption of music playback on their MacBook is going to listen to music on their iPhone instead.
    - ryandrake 5mo ago
      Maybe this is a little pedantic, but we're not talking about a default among the many other available options supported by the chip. We're talking about 48 or 96 kHz being intentionally (or unintentionally) made the only allowed options. So either someone said "we must disallow the other options" or they didn't and it's a bug.
      - rasz 5mo ago
        Imagine LCD screen capable of emitting from IR to UV and people up in arms because laptop vendor software limits output to visible spectrum.

by brynet 5mo ago

functionmouse 5mo ago

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

IshKebab 5mo ago
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 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 5mo ago
  Hardware often reports supporting 44.1kHz but internally resamples it to 48kHz so you're better off properly resampling it yourself.
- embedding-shape 5mo ago
  > 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?
  - mixmastamyk 5mo ago
    Came later I believe. They had esd and other sound “servers” back then however. Might have had to install it yourself.
  - skydhash 5mo ago
    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).
    - anthk 5mo ago
      Well, good enough it you read the OpenBSD FAQ section on Multimeda for RT throughput and the like.
  - Matl 5mo ago
    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.
    - seba_dos1 5mo ago
      Only if you had no hardware nor software mixing configured, which probably should be considered a misconfiguration of your system.
rasz 5mo ago
No its not. You wont be able to hear the difference between 44.1 vs 48.

kccqzy 5mo ago

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 5mo ago
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.
- jasomill 5mo ago
  More likely it’s that 48 kHz is a more sensible default, since the majority of non-music digital audio is sampled at 48 kHz, almost anyone who cares about potential audio artifacts introduced by resampling is going to be using an external DAC, and (from an Apple-centric viewpoint) almost anyone concerned about the energy consumption of music playback on their MacBook is going to listen to music on their iPhone instead.
  - ryandrake 5mo ago
    Maybe this is a little pedantic, but we're not talking about a default among the many other available options supported by the chip. We're talking about 48 or 96 kHz being intentionally (or unintentionally) made the only allowed options. So either someone said "we must disallow the other options" or they didn't and it's a bug.
    - rasz 5mo ago
      Imagine LCD screen capable of emitting from IR to UV and people up in arms because laptop vendor software limits output to visible spectrum.