Live data from Hacker News

Asahi Linux Progress Linux 7.0

asahilinux.org

251–260 of 385 posts

Re: Asahi Linux Progress Linux 7.0

#251
post #167

Earlier quoted context omitted.

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.

ALSA had dmix for some time already, but the default configuration of your distro may not have enabled it.

As I recall it was rarely enabled by default and was a pain to set up so in practice not really used.

The most common solution at the time was PulseAudio, which was so bad it usually was better to just use direct ALSA and live with the idiotic one-at-a-time limitation.

Thankfully Pipewire seems to actually work reliably so I guess that's at least one thing ticked off the Year of the Linux Desktop checklist.

Re: Asahi Linux Progress Linux 7.0

#252
post #67
post #58

Earlier quoted context omitted.

The real answer is probably simpler than anyone here is making it. Apple hardware margins are healthy enough that selling macbooks to linux users is pure profit, so no services lock-in needed. However, the moment they officially acknowledge Linux support, then it becomes a support surface. Every kernel panic becomes a genius bar visit. Every driver bug becomes a tweet at @AppleSupport. It's the value of plausible den…

They don't have to support it, just document the system or release their own kernel code. They don't even have to mention Linux.

They do release their own kernel code.

Re: Asahi Linux Progress Linux 7.0

#254
post #250
post #226

Earlier quoted context omitted.

In the time before PulseAudio, when it was ALSA (and OSS).

Even back then, it could play more than one stream. You had to have a sound card or kernel drivers that supported it (and all non-obsolete ones did by the time pulse audio came out). I still don’t know what purpose pulseaudio serves, other than adding latency and making stuff less reliable. PipeWire is better, but it turns out you can just use OSS under freebsd these days, and everything just works, but with lower la…

Nonsense - HDA systems were overwhelmingly the majority of Linux systems at that point, and didn't have any hardware support for multiple streams. OSS with software mixing was a commercial product that wasn't upstream. ALSA had userspace mixing but it was very much not an out of the box experience, and didn't take advantage of hardware capabilities in the way Pulseaudio did to reduce wakeups and power consumption.

Re: Asahi Linux Progress Linux 7.0

#255
post #196

Earlier quoted context omitted.

That’s called support. We count that as support.

Jesus, no, that's not called support.

As used by commercial hardware and software vendors, "support" can mean anything from "we'll come fix it for you when it breaks, or your money back" to merely "theoretically, it should work, and we won't get in the way of you trying". Likewise, "unsupported" can mean anything from "don't complain to us if it doesn't work" to "we're going to spend significant engineering effort to prevent it from working".

A stance of "here's some hardware documentation, implement the drivers yourself" definitely falls within that spectrum of "support", and is the kind of "support" for Linux that some hardware vendors have in the past been lauded for, eg. when AMD started documenting their GPUs.

That level of "support" from Apple for running Linux bare-metal on Apple Silicon would be an improvement from the status quo, and in practice would probably be sufficient to get good drivers written and upstreamed in short order, given how much interest there is in running Linux on these devices.

Re: Asahi Linux Progress Linux 7.0

#257
post #129
post #12

>.. 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 oth…

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 commit…

Presumably Apple can resample audio streams extremely cheaply.

Re: Asahi Linux Progress Linux 7.0

#258
post #83
post #71

While I absolutely love the technical write-up from the Asahi team, and being absolutely impressed by their accomplishment, to the risk of being an overly negative contrarian, I remain a bit skeptical. I'm concerned that after all these years, it's still a separate project and not an effort sustained directly within the kernel mainline and mainstream distributions like Ubuntu, Debian or Fedora. These kinds of reverse…

I think there is also the added challenge that ARM macs are a moving target, and Apple has less than no desire to provide any kind of stability or support for Asahi Linux. Unlike the PC space where laptop manufacturers have to maintain broad compatibility over time, Apple will make future changes that are really awkward for Asahi and will not care one bit because they can do the compat work on their own software.

On one hand, yes they're a moving target, on the other, they're a lot more uniform than X86 machines.

X86 can also be a moving target now; with Windows's driver autodiscovery mechanisms, manufacturers that don't care about Linux could still make people's life hell.

Re: Asahi Linux Progress Linux 7.0

#259
post #218

Earlier quoted context omitted.

> But then what is left to compare the two? Countless other things about the way they work and how they handle what you want to do with them? We're not comparing radically different things, I was intentional about my comparison of Jeep vs Civic: they're the same basic tool, with different applications and contexts where they shine. This isn't an airplane and a bicycle.

Not really - a Jeep and a Civic is pretty similar in use case still. The Mac would be more like a tram that can only go on rails vs perhaps a bus. If we want to make some useless comparison.

They are both personal computers? If anything it’s a Civic versus an Accord.

Re: Asahi Linux Progress Linux 7.0

#260
post #169

Earlier quoted context omitted.

I've run all 3 major OSes before. MacOS by far has the least bugs and kinda just works. My variosu Linux adventures have always resulted in doing random patches for audio or screen incompatibility. My windows days were plagued with battery issues. I feel like most Linux ricers wishs for a MacOS-like experience, except with more customisation. (Which is entirely possible now with the ricing on Mac)

Can macOS snap windows to the side yet without external plugins?

Yes.
Post reply on HN