Why does a freezing computer repeat the last second of audio?

[Yora]

Not sure if all computers do that, but I think all those I ever had did. The screen freezes and the speakers go into an endless loop of the last second of audio.

Why does that happen? What is sending that audio signal?

[BannedInSchool]

Not my area of expertise, but I'd guess the audio hardware is just looping through what it has loaded into its own buffer. The OS may have crashed hard, but the card/chip is operating independently.

[factotum]

What he said. It would be a very poor sound device indeed if it was expecting the CPU to feed it every single byte of audio one at a time, so they have on-board buffers that get filled with a chunk of audio. That way the CPU only has to update the audio output every second or so. If the OS crashes unrecoverably then there's nothing to feed the next block of audio to the sound card, so it'll just repeat what it has in its buffer until you hit the power button.

[Yora]

But why would these be designed to repeat the last signal instead of nothing? Is there any situation where you'd want to have the last sound again instead of silence?

[snowblizz]

But why would these be designed to repeat the last signal instead of nothing? Is there any situation where you'd want to have the last sound again instead of silence?
It's not designed to repeat the last signal, it just isn't getting any new orders. The last order it got was "play X" which is what it'll do. How is it going to decide not to play X? It doesn't have a will of it's own after all.

[BannedInSchool]

It's not designed to repeat the last signal, it just isn't getting any new orders.
I'm thinking it might be. A lot of sounds you might want a computer to play that aren't audio streams it could be handy to define some short segment for, repeated until you tell it to stop: game sound effects, alarms, etc..

[Yora]

It's not designed to repeat the last signal, it just isn't getting any new orders. The last order it got was "play X" which is what it'll do. How is it going to decide not to play X? It doesn't have a will of it's own after all.

The order could be "play sound and then stop" instead of "play sound and repeat until new signal is given".

[factotum]

I think snowblizz's answer is closest to the truth. At the very lowest level there is a single buffer playing sound out through the speakers or whatever. The rest of the hardware in the sound card, along with the CPU, changes what's in the buffer according to the sound that is currently supposed to be playing. If the CPU is off in la-la land due to the system having crashed then there's nothing to instruct the sound card to do anything different, so it will sit waiting for instructions while the last chunk of audio that was written to the buffer gets played continuously on a loop.

[snowblizz]

The order could be "play sound and then stop" instead of "play sound and repeat until new signal is given".
It could be, but obviously that was not the last order given to the chip now was it? Why would you put in stop and starts in every tiny fraction of a second in your sounds. That's millions (or something) of separate instructions that need to be acted upon for any appreciable sound.
You are insisting the chip should have acted contrary to the orders it was given, based on post hoc knowledge of the situation. The chip is not psychic. It is following the last order it was given, it can't do anything else.


I think snowblizz's answer is closest to the truth. At the very lowest level there is a single buffer playing sound out through the speakers or whatever. The rest of the hardware in the sound card, along with the CPU, changes what's in the buffer according to the sound that is currently supposed to be playing. If the CPU is off in la-la land due to the system having crashed then there's nothing to instruct the sound card to do anything different, so it will sit waiting for instructions while the last chunk of audio that was written to the buffer gets played continuously on a loop.

Few computers even have a sound card. Most make do with a chip on the motherboard translating bits into an electric signal going out one of the output jacks. It has no provision for play then stop, keep playing and so on. It works on the last bit(s) of data it got from the cpu.

The low level instructions to chips are very very very simple. After all everything is eventually rendered down into "on" or "off".
(Now I'm not a hardware expert by any means, so everything is not gonna be super accurate)

[Legoshrimp]

It could be, but obviously that was not the last order given to the chip now was it? Why would you put in stop and starts in every tiny fraction of a second in your sounds. That's millions (or something) of separate instructions that need to be acted upon for any appreciable sound.
You are insisting the chip should have acted contrary to the orders it was given, based on post hoc knowledge of the situation. The chip is not psychic. It is following the last order it was given, it can't do anything else.



Few computers even have a sound card. Most make do with a chip on the motherboard translating bits into an electric signal going out one of the output jacks. It has no provision for play then stop, keep playing and so on. It works on the last bit(s) of data it got from the cpu.

The low level instructions to chips are very very very simple. After all everything is eventually rendered down into "on" or "off".
(Now I'm not a hardware expert by any means, so everything is not gonna be super accurate)

I don't think having a separate sound card is particularly relevant. Although I guess it could have enough power to make more complex modes of operation make sense.

My guess is that most sound cards are set to constantly read a circular buffer, and it the CPUs job to make sure that buffer is updated with the new sounds. So if the CPU dies then whatever is in that buffer keeps getting repeated. In theory it could keep track of if the information is new or not, but there is no reason to really. The cpu dying isn't really a case that you care about. If that happens a reboot has to happen anyways, so there is no reason to make more complex hardware to solve a problem that won't be useful at all.

Warning: Also not a hardware expert :smalltongue:

[factotum]

Few computers even have a sound card. Most make do with a chip on the motherboard translating bits into an electric signal going out one of the output jacks.

To all intents and purposes that's still a sound card--it's just the bits happen to be integrated onto the motherboard rather than being a separate plug-in device. Some very old, very cheap motherboard sound chipsets are probably as simple as a small buffer that plays out through the jack, with the CPU having to do all the work of mixing and creating the sound in the first place, but I'm pretty sure modern ones are a lot more powerful than that.

[Knaight]

The order could be "play sound and then stop" instead of "play sound and repeat until new signal is given".

It could be, and it probably should be when designing for systems that you know will see use on sluggish computers. Lazy programming happens though, as do hardware compatibility issues. Design that doesn't cover the low end well (because programmers tend not to see much of it) also happens.

[Bulldog Psion]

You know, it's kind of hilarious to me in a way that a correctly designed sound card on a cutting edge computer has a way to duplicate the "skipping" error that an old turntable record player got when a bit of fluff got stuck on the needle. :smallbiggrin:

The more things change...

[Xuc Xac]

The order could be "play sound and then stop" instead of "play sound and repeat until new signal is given".

Or it could be "1. Play the sound in the buffer. 2. Overwrite the buffer with new input from the CPU. 3. Go back to step one." If nothing new gets put in the buffer in step two then you'll get the same sound again.

[Bohandas]

It's not designed to repeat the last signal, it just isn't getting any new orders. The last order it got was "play X" which is what it'll do. How is it going to decide not to play X?
When it has completed the order "play x"

[Tyndmyr]

It could be, and it probably should be when designing for systems that you know will see use on sluggish computers. Lazy programming happens though, as do hardware compatibility issues. Design that doesn't cover the low end well (because programmers tend not to see much of it) also happens.

Not really. This is *mostly* down in hardware. Sound card sends an interrupt when it requires additional data, cpu responds with more.

This is what happens when the CPU doesn't respond.

It's not really a problem with bad coding. People coding apps generally don't give a crap about those levels of hardware details.

The buffer needs to exist, because there's lag time between decoding and playing. Whatever's queued up for your DAC is just going to happen.


When it has completed the order "play x"

So? It's not in high level software. The structure at that level simply isn't built the way you suppose it is.

This is like complaining that you threw a bouncy ball at the floor, and wished for it to stop when it hit, instead of continuing to bounce. There is no "command" at that point, there is only physics.

[Bohandas]

Or it could be "1. Play the sound in the buffer. 2. Overwrite the buffer with new input from the CPU. 3. Go back to step one." If nothing new gets put in the buffer in step two then you'll get the same sound again.

Actually, as written it should hang at step 2.

Step 2 cannot be completed without input from the CPU.

[Douglas]

As I understand it, there are 3 pieces of hardware involved in this:

A buffer that contains a second or so of data.
A sound output device that continuously loops through that buffer, playing it from start to finish repeatedly.
A data input from the computer that's constantly racing ahead of part 2, overwriting parts of the buffer that just got played before the output cycle gets back around to them.


When a computer crashes, part 3 fails. Because of that failure, part 1 has a constant unchanging 1 second of sound, and part 2 plays it repeatedly.

Sure, speakers could be designed to stop the play loop or erase the buffer if the input stops coming, but that would increase the complexity and difficulty of designing and creating the electronics, and therefore the cost, and is completely irrelevant in normal operation. In fact, this kind of failure behavior may actually be desirable because it makes it instantly obvious that something is wrong.

[blunk]

this kind of failure behavior may actually be desirable because it makes it instantly obvious that something is wrong.Also because this could occur in unfrozen (but overloaded) systems, and the user may find stuttering sound preferable to dropouts.

[Amidus Drexel]

Few computers even have a sound card. Most make do with a chip on the motherboard translating bits into an electric signal going out one of the output jacks. It has no provision for play then stop, keep playing and so on. It works on the last bit(s) of data it got from the cpu.

The low level instructions to chips are very very very simple. After all everything is eventually rendered down into "on" or "off".
(Now I'm not a hardware expert by any means, so everything is not gonna be super accurate)



My guess is that most sound cards are set to constantly read a circular buffer, and it the CPUs job to make sure that buffer is updated with the new sounds. So if the CPU dies then whatever is in that buffer keeps getting repeated. In theory it could keep track of if the information is new or not, but there is no reason to really. The cpu dying isn't really a case that you care about. If that happens a reboot has to happen anyways, so there is no reason to make more complex hardware to solve a problem that won't be useful at all.

Warning: Also not a hardware expert :smalltongue:

I do happen to be somewhat of an expert on audio hardware and computer architecture (from a mechanical standpoint, at least), and this is basically correct on a conceptual level (technically speaking, most digital audio these days has a 16-bit or better DAC (24-bit is common, I believe), so it's a little more complicated than just "on/off", but that's the general gist of it).

How the audio system reacts to an operating system crash is going to be dependent on a couple of things - first and foremost being the audio hardware itself. A machine with a separate sound processor (see: most sound cards, some graphics cards with HDMI-out, and a lot of old video game consoles) that has control over audio output is going to react very differently to one where the audio is controlled from the main CPU. The audio driver matters here too - how it reads data input from the OS and sends that information to the audio hardware (especially with regards to commands from user applications and the OS - are they encoded as opcodes in the sound stream? Are flags set in a special register? Something else entirely?) can make a difference here too.

Another important factor would be how the computer crashes - if the GUI is non-responsive, but user applications are still running (if, perhaps, inaccessible to the user - though generally this is a graphics driver problem and not an OS problem), chances are the audio is going to continue to play as normal. If the OS partially crashes (bringing user applications and probably the UI down with it), but is still running some or most of the drivers, you have to defer to the audio driver (or the sound processor, if the system has one, though in this case the two are essentially interchangeable), and that'll largely depend on how the driver was coded. If it's designed to play through a circular buffer on repeat until it's told to stop, you'll get 1-second repeats, like you've described. If it's designed to play until it reaches an EOF flag or the end of a linear buffer (unless given an opcode to repeat), it'll stop after the buffer is exhausted. There are tons of ways you could implement this, though generally speaking you'll end up with something resembling a short repeating or terminating buffer.

If the OS completely crashes (which usually involves the kernel crashing), and the drivers stop running, the only way your sound is going to keep playing is if you have a separate processor with its own memory handling audio - but it'll still generally respond with a short repeating segment or stop after clearing its buffer. Conceivably, you could have a machine set up so that the sound processor extracted audio from physical memory, external ROM, or even the hard drive of the computer, in which case it's possible that your song would keep playing uninterrupted after such a crash (depending on how much of the audio file it has access to - most computers these days have space for a great number of complete songs in RAM, but whether it's loaded there when the computer crashes is another story), but I think most people don't do that. :smalltongue: