| Summary: | media player - audio files can be played but no sound available | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Ionut Chisanovici <ionutx.chisanovici> |
| Component: | bsps-runtime | Assignee: | Jussi Kukkonen <jku> |
| Status: | VERIFIED FIXED | QA Contact: | Cristina Agurida <cristina-danielax.agurida> |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | bogdanx.a.voiculescu, jku, ross.burton, tanuk, yp.kernel.watcher, yp.watcher |
| Version: | 1.8 | ||
| Target Milestone: | 1.9 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | 7517 | ||
| Bug Blocks: | |||
|
Description
Ionut Chisanovici
2015-03-09 13:27:15 UTC
Sending to Saul so he can find someone to look into this. The important question is what is are the test files? Changing to needinfo whilst I wait for information about what files don't play.
I'm making an educated guess: This is a NUC with both HDMI audio (in the back) and a headphone port (in the front).
My D54250WYK plays no audio through the headphones by default because there are two alsa cards, and the wrong one is the default. "aplay -l" shows two "HDMI" devices on card 0 and a "PCM" analog device on card 1. I am not sure if this is a bug though: maybe the HDMI output works by default? (I don't have hardware to test that).
If the problem is what I described, gtk-play should start working via headphones with ~/.asoundrc like this:
pcm.!default {
type hw
card PCM
}
ctl.!default {
type hw
card PCM
}
Actually, named cards didn't seem to work so:
pcm.!default {
type hw
card 1
}
ctl.!default {
type hw
card 1
}
This alsa configuration works for HDMI on D54250WYK running "core-image-sato" for "intel-corei7-64":
pcm.!default {
type plug
slave.pcm {
type hw
card 0
device 3
}
}
putting that in /etc/asound.conf makes sound work in media player.
Ross, any advice on whether I should do something about this?
So this is exactly the sort of thing that the "machine autoconfiguration" was meant to help with, but that means writing configuration files for every machine, which sucks. I'm rapidly thinking that for 1.9 we should integrate PulseAudio properly into the Sato images and let PA deal with this. For 1.8 we have to admit that raw ALSA on modern hardware is a losing battle and we can't fix this generally, and fixing it for one NUC breaks for another NUC. This issue is still present on meta-intel f9738ec19d3b2864c0bd71b9bb3418d16e922a12. The resume button(pause/play) now works. The issue can be reproduced on meta-intel: 28e8017ab8ba4f4d9e3fe5a5346bf31b3334bbbb, poky : fido-13.0.0. I used a D54250WYK NUC model for testing. The blocking bug 7517 was closed recently, but the fix is not available in fido. If you want to check if the fix for 7517 also fixes this bug, please test with the master branch of poky. Marking NEEDINFO based on Tanus comment a few months back: this needs to be retested now that pulseaudio is in use. For corei7-64 bsp, core-image-sato-sdk image on NUC hardware(model: NUCC5i5RYH) the sound works.
Verified on master poky: ea562de57590c966cd5a75fda8defecd397e6436,
meta-intel: cea00968b858b60222d68103491f076067d73876
Cheers, closing as fixed with pulseaudio integration. As per last comments set it as verified. |