error503

What does 'none of it worked' mean, here?

A USB2 cable connected to a USB3 device will still work, as USB2. This is required in the spec, and hopefully the OS provides a helpful hint here, especially if more than USB2 HS bandwidth is required.

A non-emarked cable connected to a PD source and sink will be limited to 3A@20V (60W), but again it will still work to deliver a significant amount of power, just maybe not enough.

If 'nothing' is working then something is more broken with your setup than the USB specifications.

Without USB-PD, existing phones will already limit their charge current, and Android at least will say 'charging slowly'.

The place to enforce USB-PD is at the source, which is what is happening in your described scenario.

Yes, sinks should definitely honour their power contracts, but phones generally already do this (they need to work with 500mA, 2A, and potential faster chargers without overloading them), and don't usually have power-sucking peripherals attached that will mess up their actual draw.

> Not too big of an issue at lower loads, but it will crash if I plug a hard drive in its USB port.

This hard drive probably violates USB spec, as most spinning disks do.

What you describe would be a broken charger, not a broken cable.

The charger is supposed to interrogate the cable and only offer 5A if a) the cable responds and b) responds with a 5A capability.

The 'DFP' (source) interrogates the cable, and when it advertises its capabilities to the 'UFP' (sink) it will only include what is mutually supported by the source and cable. In theory I believe the 'UFP' can also query the cable once in a contract, but not sure if this is common/ever done, I guess this capability mostly exists to inform the user if the cable they are using is insufficient.

I think it's not so much that there are too many combinations of capabilities, but more that it is hard to express the device/host constraints in a user-friendly way.

Does a 'red' stripe mean my 'green' device will or will not work? Or, confusing things further, work fine but maybe not be able to pull enough power to (fast) charge or have degraded capabilities like full speed data but no display.

IMO this is something that should be handled by the host / software and a clear nomenclature for capabilities. Notify the user if there are missing, required capabilities or performance is degraded and that they need to upgrade the cable to achieve X. As long as the cable meets the minimum USB spec this should be achievable fairly easily.

Where a marking is absolutely needed though is 'charging only' cables with no data lines. These are infuriating.

That is one solution, and in some scenarios it might not even be noticeable, but it's basically conceding the problem and accepting a guaranteed audio dropout at the end of every 'song', since for this to work you need some dead time to ensure all buffers are drained and start the new stream.

The simplest model is a source that generates a continuous audio stream, and a sink that plays it back; adding the idea of songs complicates the model, and in some use cases might be totally inappropriate. For elevator music, sure it likely doesn't matter, and maybe you can hide it in a crossfade or something with enough metadata, but this is probably part of a system where you put audio into one device connected to the network, that might include live stuff like PA announcements, and it comes out a bunch of other ones, not a dedicated elevator music system.

Yeah, Sonos is very much the Apple of this space. A solid, user-friendly implementation of several pre-existing concepts into a cohesive product - no small task. I don't think the technologically important parts of this are patentable though, there's both prior art and the obviousness standard to worry about. But very much like Apple's 'rounded corners' case, they've gone after (IMO) obvious UI functionality for such a system to extract money from their competitors.

If you are just interested in the synchronized Audio-over-Ethernet part, AES67 is the industry standard, and a pretty complete open-source implementation can be found at https://github.com/bondagit/aes67-linux-daemon , though AES67 is itself a composition of existing standards, fundamentally it is mostly composed of SDP for sessions description, RTP for media, and PTP for clock sync, so you can build that out of a variety of implementations too.

For room correction you can look at https://drc-fir.sourceforge.net/ to generate FIR filter coefficients, then you can apply it in realtime with https://github.com/wwmm/easyeffects or https://github.com/HEnquist/camilladsp .

Of course some people just want it to work, then you can shell out for Sonos :p.

In addition to GeoDNS as explained by my sibling post, this can be achieved not by making the domain point to different IP addresses, but by placing multiple instances of the same IP address in different points in the network (Anycast), and which one you hit is determined by routing policy.

Some CDNs 'prefer' one approach or the other, e.g. Akamai tends to use DNS, CloudFlare tends to use Anycast, but these days most have the capability to do both or mix them as appropriate.

The point is that nobody is going to agree to this regardless of whether they are being honest or not, because of the possibility of a bug or oversight leading to 'serious penalties'.

A fairly typical and simple approach is to set an intentional, fixed delay, say 500ms, to absorb network latency / inconsistency. The sender sends a target playback timestamp ~500ms in the future with each block of audio. Then the actual delay at the playback side can expand or contract as necessary to take up network delay. The lower you make this delay, the more care you need to take on the network side to guarantee timely delivery.

NTP is accurate enough for this, but I think most of the modern protocols in the wild e.g. AES67, AirPlay2 are using PTP. It is both more accurate and in some ways simpler for this use case.

Kind of. The bigger problem you will have if you try this is that the audio is not clocked by the system clock, and the audio clock is almost always free-running (and even if it were derived from the system clock, NTP et al don't generally discipline the clock itself, just the OS's presentation of it). So in the case of a long running playback (or continuous, as in this case), you will drift out of sync over time, and it doesn't take that long to become noticeable. And at some point you'll either start dropping out due to either buffer underflow or buffer overflow. So you do still need to take care about this.

So to work well you do need to resync the audio to the local audio clock using a sample rate converter, or build some custom hardware that lets you sync the playback audio clocks somehow. Or if you want to be sloppy about it, keep close track and stuff or drop individual samples as you drift.

But yeah, this is all more or less 'solved'.

The synth toolkit seems clearly separated as a separate project 'AMY'.

But it does seem to be two things - the syncronization and network software/firmware, and the ESP-based hardware.

There's just not much serious market for a 'build your own' server platform. Almost anyone serious buys systems prebuilt from Dell/HP/Lenovo, which have nice integrated solutions solving all of these problems, but the elements are too tightly coupled to work well in a piecemeal environment. For example, power might be distributed entirely using a backplane that the PSUs, fan trays, and motherboard all plug into. Since the market for DIY is so small, there's no real push for standardization, which would support a modular environment like standard PCs, and there's some disincentive too, since the vendors want flexibility to do cooling etc. in the best way. So what you end up with is a combination of low-volume bespoke solutions and 'ugly hacks' to make the high-volume commodity parts work in a way they weren't really designed to.

The closest that exists out there is probably SuperMicro. They have a decent variety of chassis, backplanes, motherboards and so on that work well together in a system, and the stuff is pretty decent quality. But because they are still designed for 'serious' workloads, they will not hit the cost of an equivalent desktop PC.

> First, that when some malware gets in, it looks like you.

I don't see what this has to do with trust. Whether or not there is a secure trust chain, malware can likely impersonate you.

> Second, that people who are not technically savvy will not be able to use that control to protect themselves, but will instead very often have it used against them.

If people are going to ignore the flashing red banners that pop up when they try to override the trust store that comes with their device, then that is a price we have to pay, IMO. We accept in the rest of our lives that some things are dangerous, and while we erect many barriers to make those things more difficult, we recognize that is the price of freedom. People will do them anyway, and some will be harmed. It doesn't have to be frictionless, it just has to be possible.

Is there a spate of malware going around that involves users installing new keys in their UEFI secure boot trust store? I haven't really heard of this. I also haven't really heard of a spate of malware using Android's developer mode that is pretty easy to enable, if you know how. I think the risk involved in giving users ultimate control of the device's trust store is greatly overblown.

Lightning accessories used crypto-based verification. I would be surprised if the next iteration for USB-C is not significantly stronger. So more than a simple spoof / replay attack will likely be required.

From a technical perspective, of course it is possible to give users control of the trust on the devices they ostensibly own, rather than giant megacorps, and I remain extremely unconvinced that this leads to a meaningful loss of security or privacy for those users. From a socioeconomic perspective, it's a much bigger question; the allure for those megacorps is far too strong and the economics of the industry makes it hard for society to wrest power from them, and for some reason people seem mostly okay with this status quo.

It seems to me that it's inevitable that if we let these megacorps control our devices, they will use it against us in one way or another. The only way for us as users to actually have freedom, security, and privacy is if we can control what entities the device trusts ourselves. We must create choice where the corps would rather we have none.

I will also point out that I consider Apple's rent seeking and censorship, that is more or less literally impossible to avoid, to be unethical use of this power they wield over users, and a pretty clear and meaningful way that users are harmed by it. In very concrete ways it can be considered more harmful than malware. But few seem to care enough to ask for control of their devices back, and in many of these threads more seem willing to jump to the defence of these practices than see them as a problem.

Ampere's processors are more or less fixed clock, which makes sense to me in a processor designed for cloud servers. You don't really want unpredictable performance, and in a multi-tenant situation like Oracle Cloud where I ran it, you don't want customer A's workload to affect customer B's performance running on the same physical processor.

With 10x the number of cores as the M1 Max and a TDP of 250W (maybe 5x? Apple doesn't publish numbers), the average power limit per core is likely significantly less, and the M1 might be able to leverage 'turbo' here for this short benchmark.

Still, this is not really a meaningful benchmark, just interesting.

Interesting.

I thought it would be interesting to compare the behaviour of (very) different AArch64 processors on this code.

I ran your code on an Oracle Cloud Ampere Altra A1:

  sum_slice                  time:   [677.45 ns 684.25 ns 695.67 ns]
  sum_ptr                    time:   [689.11 ns 689.42 ns 689.81 ns]
  sum_ptr_asm_matched        time:   [1.3773 µs 1.3787 µs 1.3806 µs]
  sum_ptr_asm_mismatched     time:   [1.0405 µs 1.0421 µs 1.0441 µs]
  sum_ptr_asm_mismatched_br  time:   [699.79 ns 700.38 ns 701.02 ns]
  sum_ptr_asm_branch         time:   [695.80 ns 696.61 ns 697.56 ns]
  sum_ptr_asm_simd           time:   [131.28 ns 131.42 ns 131.59 ns]

It looks like there's no penalty on this processor, though I would be surprised if it does not have a branch predictor / return stack tracking at all. In general there's less variance here than the M1. The SIMD version is indeed much faster, but by a smaller factor.

And on the relatively (very) slow Rockchip RK3399 on OrangePi 4 LTS (1.8GHz Cortex-A72):

  sum_slice                  time:   [1.7149 µs 1.7149 µs 1.7149 µs]
  sum_ptr                    time:   [1.7165 µs 1.7165 µs 1.7166 µs]
  sum_ptr_asm_matched        time:   [3.4290 µs 3.4291 µs 3.4292 µs]
  sum_ptr_asm_mismatched     time:   [1.7284 µs 1.7294 µs 1.7304 µs]
  sum_ptr_asm_mismatched_br  time:   [1.7384 µs 1.7441 µs 1.7519 µs]
  sum_ptr_asm_branch         time:   [1.7777 µs 1.7980 µs 1.8202 µs]
  sum_ptr_asm_simd           time:   [421.93 ns 422.63 ns 423.30 ns]

Similar to the Ampere processor, but here we pay much more for the extra instructions to create matching pairs. Interesting here that the mismatched branching is faster than the single branch.

I guess absolute numbers are not too meaningful here, but a bit interesting that Ampere Altra is also the fastest of the 3 except in SIMD where M1 wins. I would have expected that with 80 of these cores on die they'd be more power constrained than M1, but I guess not.

Edit: I took the liberty of allowing LLVM to do the SIMD vectorization rather than OP's hand-built code (using the fadd_fast intrinsic and fold() instead of sum()). It is considerably faster still:

Ampere Altra:

  sum_slice               time:   [86.382 ns 86.515 ns 86.715 ns]

RK3399:

  sum_slice               time:   [306.94 ns 306.94 ns 306.95 ns]

My comments in this thread are almost exclusively about the odd assertion in my parent that somehow 'anti-Apple' folks are the ones who have ignored history's lessons about monocultures. I'm not presenting this as an Apple <-> Google dichotomy; in fact nearly the opposite, both companies are fighting for monocultures that they control, just in slightly different domains. Apple wants to control the client platform, Google wants to control the web. Neither is good for users. It's very odd to me that someone would frame this discussion as 'anti-Apple' people missing the point. I won't speak for others, but I, as an anti-Apple person, am absolutely vehemently against this return to 'best viewed in IE', but I am also opposed to operating system developers and hardware vendors dictating what users are able to do with their own shit and insisting on putting their grubby paws on every dollar that passes through.

That is why I use Firefox, as the only remaining browser that hasn't shown a long-term pattern of curtailing user freedoms or rights when it suits them. I don't see Safari as a solution here; Apple is not pushing for an open web because it is righteous, they are pushing for a platform they control and to hurt their competitor. They are not to be trusted either. If they can, they will absolutely leverage that control against the user as they have shown time and time again that they are more than willing to do.

> Of course this is bullshit. Again. There's probably not a single site out there that is "best viewed in Safari". And there are numerous sites that are "best viewed in Chrome". Including, especially, the ones that Google themselves (#1 search, #1 mail, #1 video hosting, #1 web ad business in the world) creates.

When I say 'Apple', I mean 'Apple', not 'Safari'. Apple are the ones with a platform that will not run unblessed code. Apple are the ones that don't let developers or users choose how software is distributed. Apple are the ones that tell you which APIs you can and cannot use, and what your app can and cannot do. Apple are the ones that tell you what browser engine you can run, which is much stronger than a website saying 'yeah we tested this against IE, but go nuts', instead it is Apple saying 'if you want a browser engine, you can take Webkit or pound sand'. This is Apple's modus operandi, writ large. At least with Google's level of control you can still do what whatever you want with the website that runs in Chrome.

Perhaps enabling them to censor the feed is one of the primary reasons for the acquisition. I can't imagine it was that expensive, considering the likes of whom might take issue with the data being public.

Oh you're absolutely right about Chrome, I'm just not sure why you mention 'anti-Apple', because Apple's leverage is being used in many of the same ways, just much more aggressively than 'best viewed in IE', instead it's 'App Store/WebKit/<choose your monoculture> or pound sand'.

Most large airports will definitely have primary radar covering the terminal control area, but the range of these is typically only some 60nm.

Primary radar requires relatively a lot of power, and has other issues (e.g. target correlation) that make it of limited use for ATC purposes during enroute flight. If such radars exist, for military purposes for example, ATC may not have access to them as it's not really essential for their work. There are also large coverage gaps over oceans and in remote areas where nobody cares to monitor. These radars would only have a range of a couple hundred nm maximum, so they would not see deep into the Indian Ocean either.

So called 'over the horizon' radars also exist, but require truly massive amounts of power, not to mention capital to build, and also have very low spatial resolution. Apparently Australia's $1.8bn system was aimed in the wrong direction at the time of MH370's disappearance, or it might have had some low precision data to contribute.

Seems plausible, since otherwise it would be fairly simple for a third-party accessory vendor to create compatible drives that could legally sell in all the usual places you can buy console accessories.

Trademark isn't going to stop modders, but it would have been effective against legitimate accessory vendors and retailers.

TBH most everything works fine for me (unless I just don't know what I'm missing), but there is a very clear and frustrating gap with Meet backgrounds (blur etc.), which are artificially disabled on Firefox for dubious reasons.

> Many of those who have not learned from history are so anti-Apple (or possibly subpar webdevs) that they completely ignore the lessons we've previously learned about why browser monoculture is dangerous.

I'm confused, because to me it seems that the pro-Apple folks are the ones ignoring the lessons from large corporations using their weight to force monocultures.

Firefox is the only meaningful browser that is open and won't be leveraged by its steward to promote their business interests.

`sudo su` is a way.

It's not really failing silently, it's telling you through the overflow flag. To me this seems logically consistent with how one would expect overflow to behave, as it does with other instructions like ADD.

That said, I think this instruction would be safer and more useful if it still set at least the remainder result bits (which should always be valid). Then this case would not require checking, as would some other common cases like 'execute every odd iteration' kind of code.

It's "feasible" to use dynamic current sources per pixel, and many LED pixel drivers do offer this for dot correction / colour balance / global brightness, but PWM is almost always used for pixel values; it's much easier to achieve the necessary resolution staying in the digital domain, and there's not really any downside. The other big issue with current control is that the simple ways to do dynamic current are linear, so effectively use constant power regardless of pixel state, and also burn a lot of silicon area and might start creating thermal issues in the driver. At high power levels, current regulated switch mode DC-DC drivers start to make sense, but doing that per pixel is definitely not feasible.

In hindsight, sure, it seems obvious, but I don't think it was that obvious that CISC performance wouldn't end up scaling. What wasn't obvious, to me anyway, is that even with all of that complicated decode, register renaming and whatnot, these CISC processors managed to stay competitive for so long. Maybe it's just the force of inertia, though, and if there'd been a serious investment in high-performance RISC machines in the 2000s, x86 would've been left in the dust.

Does Apple pay anything meaningful to ARM? They're a founding member with (I believe still) a significant stake. I find it doubtful they didn't secure themselves a perpetual license when they founded the company, and that seems to be what the Internet believes to be true.

I'm not so sure it's the expensive large chips, made in relatively small quantities, that make ARM the most money, do you have a source? I'd have guessed they actually make more on the billions of small ARM cores that ship every year that end up by multiples in pretty much every device with a battery or power cord. And these, I think, are at the biggest risk of leaving ARM. RISC-V development is mature enough at this end of the market that it's relatively easy for users to transition, there are multiple competitive cores on the market, and there's no concern here about backwards compatibility because these are embedded systems where there's usually not an expectation of having to run user code at all. It will be much harder for the likes of Qualcomm where there's a huge ecosystem built around their ARM processors - but as a share of cost-per-processor, they probably stand to gain the most. Qualcomm is a founding member of the RISC-V foundation after all.