This is the OS side of Bug 6185 Using intel-corei7-64 as of firmware: MNW2_IFWI_X64_D_2014_04_22_1659.zip We can detect the audio device. root@intel-corei7-64:~# dmesg | grep sound [ 8.566287] sound hdaudioC0D2: autoconfig: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line [ 8.566291] sound hdaudioC0D2: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 8.566295] sound hdaudioC0D2: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 8.566298] sound hdaudioC0D2: mono: mono_out=0x0 [ 8.566300] sound hdaudioC0D2: dig-out=0x4/0x5 [ 8.566303] sound hdaudioC0D2: inputs: Interestingly, alsa only lists device 3 below, while dmesg mentions C0D2 above (Card 0, Device 2): We appear to have one digital output device as expected: root@intel-corei7-64:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 3: ID 2882 Digital [ID 2882 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 Alsamixer detects an S/PDIF Playback device and nothing else, which seems appropriate. Unfortunately, I don't hear anything when testing this device: root@intel-corei7-64:/etc# speaker-test -t sine -f 1000 -D "hw:0,3" -c2 speaker-test 1.0.27.2 Playback device is hw:0,3 Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 1000.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left 1 - Front Right Time per period = 5.638792 0 - Front Left 1 - Front Right Time per period = 5.973074 0 - Front Left 1 - Front Right
I used to run across this regularly when testing audio - the problem being that the volume was all the way down. Doing something like: amixer set master 60 or amixer set master 100 unmute would usually do the trick (To test I just cat'ed a .wav file to the device). Probably not the problem, but might be worth a try.
In this case, we only have digital output - which tends not to have a volume control, and I have confirmed it is unmuted. Just in case, I tried: root@intel-corei7-64:/etc# amixer set IEC958 100 unmute Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Note that there is no "Master" control, nor a "PCM" control - which concerns me. Note: no PCM playback devices listed here: # aplay -L null Discard all samples (playback) or generate zero samples (capture) There are at least a hardware device... maybe I have to use a plugin to get a pcm? # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 3: ID 2882 Digital [ID 2882 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 I've tried using hw:0,3 directly, but have also tried the nuc asound.conf using the dmixer plugin: pcm.!default { type plug slave.pcm "dmixer" } pcm.dmixer { type dmix ipc_key 1024 ipc_key_add_uid 0 ipc_perm 0666 slave { pcm "hw:0,3" # HDMI CARD AND DEVICE period_time 0 period_size 1024 buffer_size 8192 rate 48000 #or 44100 } } ctl.dmixer { type hw card 0 }
There may be some issue related to the HDD (?) (detect) line being active low per the GOP driver expectations, and all the other devices Dave Anders has worked with use active high. Something to discuss...
This is Yocto-specific as some of the more current distros work out of the box.
As of: # dmidecode | grep "BIOS Information" -A3 BIOS Information Vendor: Intel Corp. Version: MNW2CRB1.X64.0071.D30.1406171531 Release Date: 06/17/2014 No ALSA devices are detected at all. I veried that this image (Yocto 5/13 image) works as initially described below on the Intel E3815 NUC, so I suspect something has changed in firmware to have broken audio.
The asound.conf workaround is still needed, but the firmware as of 7/10 and later are now working. Marking this as resolved, and the OS side of things will be resolved in Bug 6362.
Firmware fix is done.