Control: forwarded -1 https://github.com/hydrogen-music/hydrogen/issues/1505 Forwarded 27 Feb 2022, but forgot to update this bug. Adrian and Reinhard, feel free to skip to "To Adrian and Reinhard:" :-) Reply follows inline: Paul Gevers <elbrus@debian.org> writes: > Hi Nicholas, > > Thanks for reaching out. > You're welcome! Sorry for my delay replying, and thank you very much for your quick reply. > On 24-02-2022 06:13, Nicholas D Steeves wrote: >> Paul and Debian CI team, do you know if a dummy alsa driver (and dummy >> sequencer driver) can be enabled on DebCI systems? > > You are in control of your testbed, can't you do this in your test? Or > can you only do this in isolation-machine testbeds (not sure how this > driver thing works)? I was thinking that this would require a `modprobe snd-dummy`, and I'm assuming loading arbitrary kernel modules is blocked on DebCI systems. It's been a few months since I contacted the CI Team about isolation-machines, but they're not yet ready for use either. > And why would only arm64 need it? > My request for snd-dummy on DebCI isn't arm64 specific; I noticed that jackd2 doesn't have autopkgtest enabled, and hypothesised that missing audio hardware was the reason why. Jackd2 maintainers are now in CC because would know better than I :-) To Adrian and Reinhard: Is there any reason why jackd2 doesn't have an autopkgtest enabled? For example, is it because it's missing functional tests, or because DebCI systems are missing something? Could Hydrogen be used to provide functional tests for jack2? Is it too much of a hassle and do you recommend just disabling autopkgtests for audio-related packages? >> This would make the >> testbed more comparable to a real system and increase the value of the >> tests for multimedia packages. If not, please feel free to skip to the >> bottom of this email. > > To be honest, I don't really like tweaking the hosts, as other > autopkgtest instances outside our control would need to learn to do this > too. > I completely understand, and the only way this request would be justifiable is if it provided a meaningful boost in quality assurance for audio-related packages. >> When I run autopkgtests locally they now error due to missing audio >> hardware where previously they passed, and this wasn't the case when the >> package was uploaded. > > The test on ppc64el now passed after several failure due to segmentation > faults. Not sure if this is now a highly flaky test, or just that the > issue has been fixed in the mean time on ppc64el > When I contacted upstream, I learned that the cause may be that the CLI utilities are poorly maintained. Is this sufficient justification for disabling the autopkgtests ie: that it's due diligence and not laziness? >> It looks to me like "allow-stderr" is no longer >> sufficient to allow the export-to-wav functional test to pass, eg: >> >> (E) JackAudioDriver::init Unknown status with JACK server. >> (E) ::H2Core::AudioOutput* H2Core::createDriver(const QString&) Error starting audio driver [audioDriver::init()] >> (E) AlsaAudioDriver::connect ALSA: cannot open audio device hw:0:No such file or directory >> (E) AlsaAudioDriver::connect ALSA: cannot open audio device default:No such file or directory >> (E) ::void H2Core::audioEngine_startAudioDrivers() Error starting audio driver [audioDriver::connect()] >> (E) ::void H2Core::audioEngine_startAudioDrivers() Using the NULL output audio driver >> (E) ::void* H2Core::alsaMidiDriver_thread(void*) Error opening ALSA sequencer: No such file or directory > > But this text is also there on passing tests. So either that's no > problem, or the test doesn't fail while it should. > I agree with you now. This output is marked "(E)", for error, but the error appears to be elsewhere. "H2Core::Instrument::dequeue(): Assertion `__queued > 0'" makes me wonder if there's something like a race somewhere that's causing an off-by-one error...and yes, most likely in Hydrogen, or introduced by a bad interaction between the almost-never-used CLI tools and the main Hydrogen engine. >> The available solutions appear to be 1) Enable a dummy sound card. 2) >> Ask upstream to support running utility functions such as this wav file >> export without attempting to bind to hardware. 3) Remove the >> autopkgtest. 4) Something else. > > Again, why only arm64? > This is no longer only arm64. See above: "When I run autopkgtests locally [amd64 system] they now error". Thank you again for having this conversation. I want to support our CI team and technical excellence rather than just "unblock migration to testing", but will of course defer to your recommendations. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature