#1328 closed bug (fixed)
devices emuxki and auich don't survive a media services restart
| Reported by: | jonas.kirilla | Owned by: | korli |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Servers/media_server | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Neither of my audio devices (the integrated auich and the emuxki) remain in the Media Preferences after having restarted the services. Both work, AFAIK. MediaPlayer can play through both. (I had to remove the drivers of the default, emuxki, to verify that the auich too works.)
This is with hrev21691 (and lots of previous revisions) on real hardware. See attached files.
(I've also mentioned this briefly in #1323 (unhandled interrupts), but I have not been able to find any correlation between unhandled emuxki interrupts and the media services losing control of these devices.)
Attachments (15)
Change History (22)
by , 17 years ago
| Attachment: | normal boot with emuxki and auich, r21691 added |
|---|
by , 17 years ago
| Attachment: | Media prefs stdout in Terminal when restarting media server added |
|---|
by , 17 years ago
| Attachment: | cat device returns error, ls -R dev added |
|---|
by , 17 years ago
comment:1 by , 17 years ago
| Owner: | changed from to |
|---|
comment:2 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
by , 17 years ago
| Attachment: | screen1.png added |
|---|
by , 17 years ago
| Attachment: | screen2.png added |
|---|
by , 17 years ago
| Attachment: | screen3.png added |
|---|
by , 17 years ago
| Attachment: | screen4.png added |
|---|
by , 17 years ago
| Attachment: | screen5.png added |
|---|
by , 17 years ago
| Attachment: | screen6.png added |
|---|
by , 17 years ago
| Attachment: | normal boot, r21696 added |
|---|
by , 17 years ago
| Attachment: | stdout in Terminal from Media prefs during restart of media services added |
|---|
by , 17 years ago
| Attachment: | serial output during restarting media services added |
|---|
by , 17 years ago
| Attachment: | gdb debug output for media addon server added |
|---|
by , 17 years ago
| Attachment: | strange media server silent segfault added |
|---|
comment:3 by , 17 years ago
Both devices show up in the Media preferences now in hrev21696, post-restart. The drivers seem fine to me, from what I can tell from serial output. But the rest : the media kit, server, addon server, preferences and the MediaPlayer all seems very fragile. See attached files and further comments.
(The screenshots and texts are not directly related. IIRC, emuxki is missing from the shots because I removed the driver temporarily to test restarting the media services with only auich. Both drivers are there in the serial/stdout/debuger capture when the media addon server crashes.)
(I don't think audio works after restarting the media services. It's not possible to choose auich - it always falls back to emuxki. When the audio works MediaPlayer leaves sliders behind in the mixer, after having been quit. Often MediaPlayer gets stuck on a playing a track.)
Please advise how to continue, if you see fit.
comment:4 by , 17 years ago
Jonas I agree with the stability problem. Typically some errors are exposed in Haiku which are not observed in BeOS. Handling correctly such errors is one thing we should fix. But errors could also originate from lower layers (libbe, kernel) :) So could you make some unit tests to identify bugs and then make new reports ?
comment:5 by , 17 years ago
I could reproduce the "gdb debug output for media addon server" and indeed a check is missing in multi_audio media addon. Though it's not the original problem (which could reside in audio drivers).
comment:6 by , 17 years ago
This whole blob of images and debug output doesn't help at all.
I'm not going investigate this mess further.
Appereantly you found a least a single bug in the hmulti_audio-addon WriteZeros function. Please file a separate bug report for this if you want to help us. Please do not reopen this ticket.
comment:7 by , 17 years ago
The segfault in WriteZeros() should be fixed in hrev21758. It actually shows a problem in the driver. So it would greatly help if you can test each audio driver one after the other and open new bugs. Thanks.
Should be fixed as of hrev21696