spoiler

made you look

  • 0 Posts
  • 14 Comments
Joined 11 months ago
cake
Cake day: July 27th, 2024

help-circle
  • From a quick search it seems that the mobo uses a Realtek audio chip, which is probably the actual problem. My current system build uses one and it barely worked under Windows, it’d randomly remap the channels, sometimes it just wouldn’t come up properly (Showed as only a microphone, etc.), had lots of static noise, would constantly think I was unplugging and replugging headphones in, etc. Just a terrible experience compared to the Intel audio system the build before this used.

    As much as “just buy another bit of hardware” is an awful bit of advice, I’d recommend getting a USB DAC/soundcard, I bought a cheap soundblaster one and it fixed all my problems. USB audio is a well-defined standardised protocol that’s supported by just about everything, does away with any driver issues or incompatibilities, can be moved between devices, etc. Mine’s a “gaming” model so it’s just a USB port on one side and a headset jack on the other, but you can also get ones with proper inbuilt amplifiers to run full speaker kits, etc.



  • A place I worked at did it by duplicating and modifying a function, then commenting out the existing one. The dev would leave their name and date each time, because they never deleted the old commented out functions of course, history is important.

    They’d also copy the source tree around on burnt CDs, so good luck finding out who had the latest copy at any one point (Hint: It was always the lead dev, because they wouldn’t share their code, so “merging to main” involved giving them a copy of your source tree on a burnt disk)












  • They’re “file like” in the sense that they’re exposed as an fd, but they’re not exposed via the filesystem at all (Unlike e.g. unix sockets), and the existing API is just mapped over the sockets one (i.e. write() instead of send(), read() instead of recv()). There’s also a difference in how you create them, you open() a file, but connect() a socket, etc.

    (As an aside, it turns out Bash has its own virtual file-based wrapper around sockets, so you can do things like cat a remote port with Bash, something you can do natively in Plan 9)

    Really it just shows that “everything is a file” didn’t stand up in practice, there’s more stuff that needs special treatment than doesn’t (e.g. Interacting with TTYs also has special APIs). It makes more sense to have a better dedicated API than a generic catch-all one.