Do the speakers require the Content-Type header to be set? If not, POST wouldn't require CORS permissions.
They do require the Content-Type header
Reverse-engineering my speakers' API to get reasonable volume control
51–60 of 144 posts
Re: Reverse-engineering my speakers' API to get reasonable volume control
#52Nice speakers! I'm guessing the model, if correct here are some spins for those interested https://www.erinsaudiocorner.com/loudspeakers/jbl_4329p/ Weird you can't limit digital output. I also listen mostly at low volumes and have the same issue. Part of the reason I chose Sonos is this is built in across all products, alongside an effective loudness toggle. This has been particularly helpful with some little Genelec…
How are you going with the new Sonos app upgrade?
Perfectly fine, I actually prefer it in almost every way.
The only issue I agree is truly serious is the latest release draining battery on iOS with or without background activity disabled. That’s a real bad bug to introduce and I’m surprised it hasn’t been fixed yet.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#53> 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.
Volume controls also shouldn't just be a flat wideband gain - they should respect how we actually perceive sound so the timbre doesn't change as the level changes (when you turn the volume down, you are typically left with just the stuff in the vocal frequency range, and lose all the bass etc).
Doing this stuff well is pretty hard (e.g. designing filters that can do that kind of volume adjustment is hard because you want to be constantly adjusting them, which means you need to be super careful with your filter state) but I have heard what it sounds like, and once you hear it you get angry at all other volume controls.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#54I wish someone would solve the opposite problem in PCs and laptops—that of too little audio gain. Designers never leave any gain in reserve for when audio input levels are too low. Why do they do this? The problem is so obvious that you'd reckon they're doing it to deliberately annoy users. The problem doesn't stop there, the lack of gain with Bluetooth is notorious. Almost every Bluetooth device I own has insufficie…
Just use Linux, you can set all sorts of gains and limits on Pulse Audio, for each app and speaker individually.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#55Earlier quoted context omitted.
Tangential fun fact: amps have a fixed gain, because it's hard to make a variable gain without distortion [1]. The volume knob doesn't control amplification, in fact it controls an attenuation stage, because it's easier to make variable attenuation with low distortion. [1] that's why there were so many different "classes" of amps, they're all making different tradeoffs about how they're doing the amplification.
According to Claude, the attenuation stage is before the power amp stage. Does that mean worse SNR whether the volume is controlled using the volume control or via the input? (Ignoring the additional quantization issue with a scaled digital input.)
You could put the attenuation stage after the power amp stage but it would require big beefy resistors that could absorb a lot of power. They'd get hot and the whole thing would be very inefficient.
But hey, very low distortion.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#56Seems like the author moved from a “speakers + networked amp” setup, to a one where with active speakers where everything is built-in. When I was buying speakers for my apartment some time ago, I was similarly considering going for the all-in-one options like this, but I’m glad I didn’t. I prefer the “dumb passive speaker + networked amp”, as it allows you to pick / replace / upgrade the separate components. Went for…
> Seems like the author moved from a “speakers + networked amp” setup, to a one where with active speakers where everything is built-in.
Close! I moved from a "speakers + non-networked amp + streamer" setup.
I'm still running separate components for nearer-field listening at my desk, where I've got KEF Q150s powered by a small Schiit pre-amp and amp.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#57> 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.
Volume controls also shouldn't just be a flat wideband gain - they should respect how we actually perceive sound so the timbre doesn't change as the level changes (when you turn the volume down, you are typically left with just the stuff in the vocal frequency range, and lose all the bass etc). Doing this stuff well is pretty hard (e.g. designing filters that can do that kind of volume adjustment is hard because you…
> Volume controls also shouldn't just be a flat wideband gain - they should respect how we actually perceive sound so the timbre doesn't change as the level changes (when you turn the volume down, you are typically left with just the stuff in the vocal frequency range, and lose all the bass etc).
The amp I'm upgrading from was interesting in this regard. In addition to the main volume knob, it had a loudness knob. The manual actually recommended keeping the volume knob fixed most of the time and using the loudness knob to set the listening level throughout the day.
From the manual:
> 1. Set the LOUDNESS control to the FLAT position.
> 2. Rotate the VOLUME control on the front panel (or press VOLUME +/– on the remote control) to set the sound output level to the loudest listening level that you would listen to.
> 3. Rotate the LOUDNESS control counterclockwise until the desired volume is obtained.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#58Why do speakers even expose a web api in the first place? It’s just easily available without any security? Hope this person segmented this device away from other devices. The lack of basic security in the IoT space is astounding to me.
I was looking for this comment. Basically he managed to get a sort of unauthenticated R/W access to the file system.
This is really concerning
Re: Reverse-engineering my speakers' API to get reasonable volume control
#59> 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.
Yep. I was always using only the low end of the volume slider and having the same problem as OP that the steps were too coarse. So for Musium, I added a logarithmic volume control with a step size of 1 dB. That difference is on the border of being perceivable in the range I usually listen at, which is fine enough in practice.
Re: Reverse-engineering my speakers' API to get reasonable volume control
#60I wish someone would solve the opposite problem in PCs and laptops—that of too little audio gain. Designers never leave any gain in reserve for when audio input levels are too low. Why do they do this? The problem is so obvious that you'd reckon they're doing it to deliberately annoy users. The problem doesn't stop there, the lack of gain with Bluetooth is notorious. Almost every Bluetooth device I own has insufficie…
> 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 running flat out is difficult enough. And my hearing is fine.
And where are the regulations that specify a maximum sound level rating for laptops?
By comparison, my 4.5 x 2.5" palm-size Sony transistor radio type ICF-510MK2 (which I'm currently holding in my hand) not only has stacks and stacks of gain on very low level audio (I've never needed to turn the volume up past halfway), and it simply blows my expensive Lenovo laptop away when it comes to maximum output level (I've no trouble hearing it several rooms away). There are no regulations covering how loud it sounds. OK, I've now given everyone a reference device for comparison. I'd put it up against any laptop I've heard in recent times and it'd win hands down every time. BTW, I only paid $9 for it but that was a few years back.
You're right about the bits, it was a throwaway figurative comment to make a point.
I cannot understand why so many people come to the defence of poor ratshit design. My expensive Lenovo laptop, like my Dell laptop, are not fit for purpose when it comes to the audio subsystem. If I can't hear it on a nominal range of audio signals such as those mentioned from Google then, by definition, they're not fit for purpose.
The same nonsense has been wheeled out in recent days in defense of Microsoft's BSOD/crash. As I said on another post that Dark Ages Windows OS ought to be ditched or rewritten (once running, BSODs should never occur unless there's a hardware fault no matter what's loaded into the kernel). If it goes belly-up then it's bad design, QED.
Why defend the indefeasible? That people do and don't complain is why our lives are surrounded by so much shitty partially-functioning tech.