I love this. Thanks for posting. Your Father and Mother must be very proud of you.
Are you perhaps related to the author?
Reverse-engineering my speakers' API to get reasonable volume control
121–130 of 144 posts
Re: Reverse-engineering my speakers' API to get reasonable volume control
#122Re: Reverse-engineering my speakers' API to get reasonable volume control
#123Earlier quoted context omitted.
> Why do they do this? So they don't damage users' speakers, their hearing, or generally cause annoyance. > They just assume a 16-bit input has 65536 levels and that's the range. Full stop! They never give consideration to what happens when the peak audio input covers perhaps less than one third that range of bits. 1/3 of 65536 is still +-11,000 voltage levels, or 14.4 bits of information. That's a really good place…
"So they don't damage users' speakers, their hearing, or generally cause annoyance." Damage speakers? Simply, not an issue unless they're one step removed from rubbish. Also, have you ever heard of output compression and clipping that would protect them? That approach is 101 electronics. Hearing is not an issue as they're driven by flea power (they're not headphones). Even hearing these pissy little speakers when run…
> Damage speakers? Simply, not an issue unless they're one step removed from rubbish. Also, have you ever heard of output compression and clipping that would protect them? That approach is 101 electronics.
Output clipping actually increases power at high frequencies.
So your 2003-era Japanese radio has better output than a Chinese laptop.
> are not fit for purpose when it comes to the audio subsystem
Consider the possibility that they're fit for a purpose other than yours. Maybe they're not intended to be used for sound reproduction.
> That people do and don't complain is why our lives are surrounded by so much shitty partially-functioning tech.
You're the one who bought the laptops without listening to the speakers first.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#124> Those methods either give me a tiny slider that I can only use 10% of or about 15 steps where the jump from step 3 to step 4 takes the speakers from “a bit too quiet” to “definitely bothering the neighbors” levels. Volume controls need to be logarithmic, not linear. To a first degree approximation, everybody gets this wrong.
Even friggen Apple, who seem to have a rep for caring about such things. I'd say I'd need at least 5 more levels between off and the lowest volume on my iPhone. It's way too loud to use in a quiet room. I have to try to cover the speaker.
I use Sonos speakers.
They let me set the maximum volume (about 50% of actual max). The increments in iOS then get smaller.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#125Hey OP - if your thinking about a smart knob with haptic feedback etc - check this open source project out that you can build yourself - its amazing: https://github.com/scottbez1/smartknob Video demo here: https://www.youtube.com/watch?v=ip641WmY4pA&t=1s
Wow! I had dreamed of physical "analog" controls as a standard feature on keyboards and input devices for various applications -- would be great productivity booster for power users. I wish this catches on and gets mass adoption.
Dell had this. Also a button to get instant silence, and an USB port for the mouse.
https://universaldatasystems.org/shop/wp-content/uploads/201...
Re: Reverse-engineering my speakers' API to get reasonable volume control
#126Earlier quoted context omitted.
Sure from a longevity perspective, you are 100% correct and for HIfi/Home use I'd recommend the same. I am not sure however if your estimation is correct for all cases. The amount of killed tweeters I have seen would not have happened with an active speaker..
> I am not sure however if your estimation is correct for all cases. Apologies. Next time they'll do a 10-year study on the subject before daring to comment on a public forum, ensuring that each and every angle is covered so that le smart folks like yourself will be able to sleep at night.
No need to be bitter. I don't even know you, so I mainly said my experience is different.
Now maybe that is because I am an electronics guy and people come to me with their broken stuff and I see what actually breaks, but isn't the point of a public forum to say something and be occasionally wrong? Should I rather have stayed silent?
I don't know about you, but if some knowledgeable person corrects me, I am grateful for getting a check on my perspectives. This is the value of discussion.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#127Earlier quoted context omitted.
Sure from a longevity perspective, you are 100% correct and for HIfi/Home use I'd recommend the same. I am not sure however if your estimation is correct for all cases. The amount of killed tweeters I have seen would not have happened with an active speaker..
>The amount of killed tweeters I have seen would not have happened with an active speaker. My 1978 (no brand) speakers are still in excellent condition, so are the 1991 Bose. Hifiberry works fine. ymmv
Yeah, my mileage is running a media technology rental in one of the biggest art universities of Europe.
And as a known electronics guy people bring their broken stuff to me for at least the last decade.
If you handle stuff correctly it will survive. But the point about reliability is to also take into account how stuff survives when it is abused.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#128Re: Reverse-engineering my speakers' API to get reasonable volume control
#129I clicked on this article with so much excitement and hope… ah darn, not my speaker.
Sonos volume control remains broken in their new (forced) app update, “reasonable control” on the roadmap for two months out
Re: Reverse-engineering my speakers' API to get reasonable volume control
#130Pro-tip for embedding JS in an HTML string in a Typescript file: you can get full typecheck etc for your embedded JS snippet if you write it as a top-level function in your file, and then interpolate the function into your template. This works because function.toString() in modern runtimes gives you back fully parse-able input source. You need to make sure you don’t reference anything outside the function, but it’s g…
Funnily, I had a backend function that used `window`, which was then sent to frontend in this way. I think the project's tsconfig `lib` included `dom` for it to work.
Overall a nice technique!