Protections against faulty music pressings (Liz?)

At what point is the A/D converter placed?

We hashed this out last night:

- Parse the program BEFORE committing to the store to determine any malevolent content; let user preview those and make judgement

- Guarantee the integrity of the stored program (so, if it was deemed 'OK', it will thereafter be 'OK')

- Treat retrieval (from store) as HRT

- Treat local signal processing as HRT

- Treat delivery (to player) as HRT

- As with *any* HRT, missed deadline terminates the job (by definition)

- Learn signs of *likely* deadline misses and terminate in anticipation

- Advise workload manager of any potential to shed conflicting loads (this assumes deadline misses are not attributable to failures)

This should work well for *stored* content. Handling *live* content delivery will require a bit more thought. And, likely a different signal path.

If the ultimate source is microphones or guitar pickups, those analog signals are soon digitized and it's all DSP from there.

If the music is synthesized or AI generated, there is no ADC.

Is AI composing music nowadays? That should be obvious now or soon.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Not certain about CD players, but at the time of my thesis (2001), streaming services would often replace missed 'chirps' (the combination of some bits to make a sound, not certain what this is referred to), with the previous successful chirp. As you mentioned, they use the around information, this is an example of the specifics of that. Perhaps more could be done by including future chirps in this method, such as interpolation between the two. I'm interested in finding out what the common method is in streaming today.

The problem boils down to: the "solution" is failing. So, do you hope it magically fixes itself?

I *know* the original content is intact (for stored content). So, if it is not getting to the player in a timely fashion, some other aspect of the implementation is "broken". Will compensating for that *now* ensure there are no further signs of breakage? Or, could/will these "problems" keep manifesting every few seconds -- and, what would that do to the listening experience? Or, could the entire rest of the program end up elided (depending on the nature of the problem)??

Elevate the problem to someone (something) who can make a better decision about it.

E.g., if the program you are reproducing is "wakeup music" in lieu of an "alarm", then perhaps you should replace it with an alarm to, at least, ensure the user gets the wakeup notification they desired.

If the problem is a consequence of the media store being over-subscribed, maybe drop some subscribers?

Or, the network saturated?

Or, the local node having too high of a workload to handle the needs of the media client?

But, surely an individual client is not qualified to determine which OTHER clients/activities should be altered! Though, knowing *it* isn't performing as expected, then *it* shouldn't continue WASTING resources that aren't achieving their intended goal.

Google hd radio home receivers There's a bunch of them. This is not to oppose your point (see below), just some information.

That's not surprising - there is not wide usage of HD radio in home environments. As you noted, it is mostly used in vehicles.

Ed

Sorry I meant for a receiver, processing a signal from an antenna.

I did. I note most are made by a taiwanese company Sangaean. To be fair, they seem to offer many models at different price points.

My goal is to have all (non Internet) network-sourced content (ATSC-TV, FM, AM, FM-HD, stored content, etc.) so buying a tabletop radio is just an item I will be discarding, RSN.

E.g., route content from a "headless black box" to a targeted sink without having to put that box in the living space (on a tabletop, on a wall, etc.)

An SDR seems the ideal approach for the lower-bandwidth sources as it can do double-duty for other "broadcasts" instead of having to have a radio for each possible use.