>>> <SNIP> >>>> >>>> But in the end, there's really no way to know, right? From what I >>>> gather, jack can add another buffer and report on it, but it's the >>>> sound card buffer that determines whether there are problems or not, >>>> right? >>> >>> No, I think Jack does know. >>> >>> In non-Jack apps the application pumps out data. If the buffers >>> overflow or run empty it's just a 'system problem' and the system has >>> failed. >>> >>> In Jack apps all audio is moved by Jack. All Jack apps are callback >>> based. Jack itself issues a demand for data from the application, then >>> if the application supplies it then everything works correctly. If the >>> app doesn't supply the data then we know where the problem is and we >>> can fix it. >> >> Here's how I understand it. In a system without jack, there is >> communication between the system and the sound card. With jack, there >> is communication between the system and jack, and also between jack >> and the sound card. It sounds like jack can report on problems with >> communication between the system and jack, but we are still left in >> the dark as far as communication problems between jack and the sound >> card. >> > > I don't think so. Jack will report if it had trouble delivering the > data to the card. It's just another xrun.
Is that enough information to be sure the card's buffer never runs dry? > <SNIP> >> >> Was it the Asus motherboard? Did it take anything else out with it? >> > > Asus A8N-E. The crash took out the motherboard, the power supply and > possibly a disk drive. At least I cannot get the drive to spin up and > it was a new SATA drive that was the main system drive before the > machine died. I'm really sorry to hear this. I hope you were able to resuscitate the drive. Did you choose a reliable motherboard to replace the Asus? If so, I'm interested to hear how you made a reliability determination. How's temperature in the case? - Grant
