November 2008 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] S24_BLE does not play using aplay.
by Sean McNamara 13 Nov '08

13 Nov '08

Hi, >>> On Thu, Nov 13, 2008 at 2:07 PM, Baek Chang <baeksan(a)ccrma.stanford.edu> >>> wrote: >>> > Thanks for the reply. I get the following error when trying your >>> > suggestion >>> > >>> > aplay --device=plug:pulse LPCM_48khz_ST_24bit.wav >>> > >>> > Playing WAVE 'LPCM_48khz_ST_24bit.wav' : Signed 24 bit Little Endian in >>> > 3bytes, Rate 48000 Hz, Stereo >>> > aplay: set_params:1022: Unable to install hw params: >>> > ACCESS: RW_INTERLEAVED >>> > FORMAT: S24_3LE >>> > SUBFORMAT: STD >>> > SAMPLE_BITS: 24 >>> > FRAME_BITS: 48 >>> > CHANNELS: 2 >>> > RATE: 48000 >>> > PERIOD_TIME: 125000 >>> > PERIOD_SIZE: 6000 >>> > PERIOD_BYTES: 36000 >>> > PERIODS: 4 >>> > BUFFER_TIME: 500000 >>> > BUFFER_SIZE: 24000 >>> > BUFFER_BYTES: 144000 >>> > TICK_TIME: 0 >>> > >>> > >>> > Any ideas? >>> > >>> > Thanks >>> > Baek >>> > Some initial debugging shows: 1. It's not in alsa-plugins/pulse, because if you send it 24-bit anything, it won't recognize that format and error out with a different message (rather than just throwing error back at aplay). Things fall down before pcm_pulse.c ever evaluates the sample format. 2. It's not in alsa-lib/pcm/pcm_plug.c, because plug intelligently works with other (non-pulse) devices: Works: aplay --device=plug:hw:0 LPCM_48khz_ST_24bit.wav and aplay --device=plug:dmix:0 LPCM_48khz_ST_24bit.wav In theory, these statements should be both true: My hw doesn't support S24_3LE, but plug converts it for me. My pulse doesn't support S24_3LE, but plug converts it for me. But there is one more layer between plug and the actual pulse plugin code: ioplug! It's non-trivial to figure out the guts of functions such as snd_pcm_ioplug_hw_refine when you have refine math going on. The refine code goes through a lot of contortions trying to get ioplug to accept a conversion, but no joy.... it appears pcm_extplug.c, the "External Filter Plugin SDK" is unhappy. So basically, the problem occurs before alsa-plugins/pulse even gets a chance to detect and deal with the problem. pcm_ioplug.c does something similar to what pcm_plug.c does with refines, just more cryptically. Since it was developed so long ago, it may not have been tested with S24_3LE, or with S24 at all. One possible ugliness is that there is no cmpxchg instruction for 24-bit values, so you'd have to do something else for synchronization. Maybe that's why it's not supported? It sounds like pulse (or any ioplug-user, in general) is not going to support S24_3LE until someone really digs in and finds out why this is erroring out. Keep in mind that there are two code paths that both hit the same problem, namely plug:pulse and pulse alone. The error returned is different, and it seems simpler to figure out why you get an error with plain pulse, rather than complicating things with plug. HTH, Sean >>> > >>> > On Thu, Nov 13, 2008 at 11:04 AM, Sean McNamara <smcnam(a)gmail.com> >>> > wrote: >>> >> >>> >> Hmm, sounds like the ALSA<->Pulse bindings don't support this sample >>> >> format. Have you tried >>> >> >>> >> aplay --device=plug:pulse foo.wav >>> >> >>> >> Maybe the ALSA plug layer can convert it to a sample format that the >>> >> pulse plugin will accept. I don't have a file like this so I can't >>> >> test. >>> >> >>> >> Sean >>> >> >>> >> On Thu, Nov 13, 2008 at 1:44 PM, Baek Chang >>> >> <baeksan(a)ccrma.stanford.edu> >>> >> wrote: >>> >> > I am using pulseaudio as the sound server in conjunction with alsa. >>> >> > My >>> >> > alsa >>> >> > sinks are mapped to pulseaudio in asound.conf. Using paplay with a >>> >> > 24 >>> >> > bit >>> >> > file seems to work fine, because pulseaudio just converts the S24 >>> >> > bit >>> >> > data >>> >> > to 32 bit float. Is there a way to bypass using plughw with alsa, >>> >> > so >>> >> > that >>> >> > alsa can just send the 24 bit pcm data to pulseaudio, then have >>> >> > pulseaudio >>> >> > do the neccessary conversion? >>> >> > >>> >> > Thanks >>> >> > Baek >>> >> > >>> >> > On Fri, Nov 7, 2008 at 6:08 AM, Clemens Ladisch <clemens(a)ladisch.de> >>> >> > wrote: >>> >> > >>> >> >> Baek Chang wrote: >>> >> >> > Playing WAVE 'sine_24_48k.wav' : Signed 24 bit Little Endian in >>> >> >> > 3bytes, >>> >> >> Rate 48000 Hz, Stereo >>> >> >> > aplay: set_params:961: Sample format non available >>> >> >> >>> >> >> This error message indicates that the device does not support the >>> >> >> sample >>> >> >> format. >>> >> >> >>> >> >> You didn't show the aplay command line, but I'd guess that you used >>> >> >> a >>> >> >> "hw" device. Try "plughw" or "default" to get automatic sample >>> >> >> format >>> >> >> conversion. >>> >> >> >>> >> >> >>> >> >> HTH >>> >> >> Clemens >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > -- >>> >> > Baek Chang >>> >> > baeksan(a)ccrma.stanford.edu >>> >> > 407-267-6701 >>> >> > _______________________________________________ >>> >> > Alsa-devel mailing list >>> >> > Alsa-devel(a)alsa-project.org >>> >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>> >> > >>> >> >>> > >>> > >>> > >>> > -- >>> > Baek Chang >>> > baeksan(a)ccrma.stanford.edu >>> > 407-267-6701 >>> > >> >> >> >> -- >> Baek Chang >> baeksan(a)ccrma.stanford.edu >> 407-267-6701 > > > > -- > Baek Chang > baeksan(a)ccrma.stanford.edu > 407-267-6701 >

1 0

[alsa-devel] Creative Sound Blaster X-Fi and X-Fi Titanium Series Linux 32bit/64bit Driver Source released
by Bjoern Olausson 13 Nov '08

13 Nov '08

Creative released a driver today.... I am hasitating to install it.. the last one was so crappy and I just installed my gentoo new ;-) But it looks really like the SOURCE, so maybe it will help to pimp the ALSA driver (would rather see an implementation in alsa then an driver from Creative) http://forums.creative.com/creativelabs/board/message?board.id=soundblaster… http://support.creative.com/downloads/download.aspx?nDownloadId=10792 Kind regards Bjoern

9 23

[alsa-devel] S24_BLE does not play using aplay.
by Baek Chang 13 Nov '08

13 Nov '08

Hi, I am testing some things with aplay and I am trying to play a stereo Signed 24-bit 3 byte, 48kHz PCM file. I get the following error: Playing WAVE 'sine_24_48k.wav' : Signed 24 bit Little Endian in 3bytes, Rate 48000 Hz, Stereo aplay: set_params:961: Sample format non available Does aplay only work for S24_LE in 4 bytes? Thanks in advance Baek

2 2

[alsa-devel] Asus P5QL-EM motherboard (ALC1200 codec) - no sound through S/PDIF
by Andrei Tanas 13 Nov '08

13 Nov '08

Hello, I can't get the S/PDIF out to work on P5QL-EM motherboard. First of all, it doesn't detect the board configuration correctly, the motherboard has an HDMI output and an S/PDIF header (I have a TV connected to one and an amplifier to the other, in case one output will "go live"). aplay -L normally only shows th HDMI port, however if I add this options snd-hda-intel model=6stack-dig probe_mask=1 to /etc/modprobe.d/alsa-base, it will show both. Problem is, there seems to be no signal coming out of any of the two digital ports (they are not muted in mixer) in either PCM or AC3 pass-through mode. I compiled the "alsa-kernel" hoping that the latest commits related to ALC1200 would help, but it hasn't helped. Here's the output of alsa-info.sh: http://www.alsa-project.org/db/?f=b62b56c5ce0aa383fef1be0f55b87b4e27e8ab63 Again, it's running "alsa-kernel", checked in just 12 hours ago. Let me know what I can do to help, I am a developer but Alsa is not my territory. Thanks

3 14

[alsa-devel] [PATCH RESEND 2/2] Adds audo definition for SMDK2410
by Christian Pellegrin 13 Nov '08

13 Nov '08

Adds audio support for SMDK2410 Generated on 20081113 against f7e1798a78a30bae1cf3ebc3e1b6f7c1bac57756..5b7f05e9b57e7e442b1054cbb4423cf9909fb204 Signed-off-by: Christian Pellegrin <chripell(a)fsfe.org> --- arch/arm/mach-s3c2410/mach-smdk2410.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s3c2410/mach-smdk2410.c b/arch/arm/mach-s3c2410/mach-smdk2410.c index 152527b..0001d52 100644 --- a/arch/arm/mach-s3c2410/mach-smdk2410.c +++ b/arch/arm/mach-s3c2410/mach-smdk2410.c @@ -43,6 +43,7 @@ #include <asm/mach/irq.h> #include <mach/hardware.h> +#include <mach/regs-gpio.h> #include <asm/irq.h> #include <asm/mach-types.h> @@ -53,6 +54,8 @@ #include <plat/common-smdk.h> +#include <sound/s3c24xx_uda134x.h> + static struct map_desc smdk2410_iodesc[] __initdata = { /* nothing here yet */ }; @@ -85,12 +88,27 @@ static struct s3c2410_uartcfg smdk2410_uartcfgs[] __initdata = { } }; +static struct s3c24xx_uda134x_platform_data s3c24xx_uda134x_data = { + .l3_clk = S3C2410_GPB4, + .l3_data = S3C2410_GPB3, + .l3_mode = S3C2410_GPB2, + .model = UDA134X_UDA1341, +}; + +static struct platform_device s3c24xx_uda134x = { + .name = "s3c24xx_uda134x", + .dev = { + .platform_data = &s3c24xx_uda134x_data, + } +}; + static struct platform_device *smdk2410_devices[] __initdata = { &s3c_device_usb, &s3c_device_lcd, &s3c_device_wdt, &s3c_device_i2c, &s3c_device_iis, + &s3c24xx_uda134x, }; static void __init smdk2410_map_io(void) -- 1.4.4.4

1 0

[alsa-devel] [PATCH] ASoC: DaVinci: Audio: Fix swapping of channels at start of stereo playback
by naresh＠ti.com 13 Nov '08

13 Nov '08

From: Naresh Medisetty <naresh(a)ti.com> Fixes swapping of channels at start of stereo playback. Channel swap can be observed while playing left-only or right-only audio data. The channel swap is fixed by handling the XSYNCERR condition. Signed-off-by: Naresh Medisetty <naresh(a)ti.com> --- sound/soc/davinci/davinci-i2s.c | 49 ++++++++++++++++++++++++++++++++++++-- 1 files changed, 46 insertions(+), 3 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index 5ebf1ff..d8279ad 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -110,16 +110,59 @@ static void davinci_mcbsp_start(struct snd_pcm_substream *substream) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct davinci_mcbsp_dev *dev = rtd->dai->cpu_dai->private_data; + struct snd_soc_device *socdev = rtd->socdev; + struct snd_soc_platform *platform = socdev->platform; u32 w; + int ret; /* Start the sample generator and enable transmitter/receiver */ w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG); MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_GRST, 1); - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w); + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + /* Stop the DMA to avoid data loss */ + /* while the transmitter is out of reset to handle XSYNCERR */ + if (platform->pcm_ops->trigger) { + ret = platform->pcm_ops->trigger(substream, + SNDRV_PCM_TRIGGER_STOP); + if (ret < 0) + printk(KERN_DEBUG "Playback DMA stop failed\n"); + } + + /* Enable the transmitter */ + w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG); MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_XRST, 1); - else + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w); + + /* wait for any unexpected frame sync error to occur */ + udelay(100); + + /* Disable the transmitter to clear any outstanding XSYNCERR */ + w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG); + MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_XRST, 0); + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w); + + /* Restart the DMA */ + if (platform->pcm_ops->trigger) { + ret = platform->pcm_ops->trigger(substream, + SNDRV_PCM_TRIGGER_START); + if (ret < 0) + printk(KERN_DEBUG "Playback DMA start failed\n"); + } + /* Enable the transmitter */ + w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG); + MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_XRST, 1); + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w); + + } else { + + /* Enable the reciever */ + w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG); MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_RRST, 1); - davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w); + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w); + } + /* Start frame sync */ w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG); -- 1.5.4.1

3 4

[alsa-devel] [PATCH] ARM DaVinci: Add Right-Justified mode and Codec clock master to davinci-i2s
by hugo.villeneuve＠lyrtech.com 13 Nov '08

13 Nov '08

From: Hugo Villeneuve <hugo.villeneuve(a)lyrtech.com> ARM DaVinci: Add Right-Justified mode and Codec clock master to davinci-i2s The TI DVEVM board uses the SND_SOC_DAIFMT_CBM_CFM & I2S formats, but the Lyrtech SFFSDR board uses the SND_SOC_DAIFMT_CBM_CFS & RIGHT-JUSTIFIED formats. Signed-off-by: Hugo Villeneuve <hugo.villeneuve(a)lyrtech.com> --- sound/soc/davinci/davinci-i2s.c | 40 ++++++++++++++++++++++++++++++++------ 1 files changed, 33 insertions(+), 7 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index abb5fed..d814ec8 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -59,6 +59,7 @@ #define DAVINCI_MCBSP_PCR_CLKXP (1 << 1) #define DAVINCI_MCBSP_PCR_FSRP (1 << 2) #define DAVINCI_MCBSP_PCR_FSXP (1 << 3) +#define DAVINCI_MCBSP_PCR_SCLKME (1 << 7) #define DAVINCI_MCBSP_PCR_CLKRM (1 << 8) #define DAVINCI_MCBSP_PCR_CLKXM (1 << 9) #define DAVINCI_MCBSP_PCR_FSRM (1 << 10) @@ -171,6 +172,16 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SRGR_REG, DAVINCI_MCBSP_SRGR_FSGM); break; + case SND_SOC_DAIFMT_CBM_CFS: + /* McBSP CLKR pin is the input for the Sample Rate Generator. + * McBSP FSR and FSX are driven by the Sample Rate Generator. */ + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, + DAVINCI_MCBSP_PCR_SCLKME | + DAVINCI_MCBSP_PCR_FSXM | + DAVINCI_MCBSP_PCR_FSRM); + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SRGR_REG, + DAVINCI_MCBSP_SRGR_FSGM); + break; case SND_SOC_DAIFMT_CBM_CFM: davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, 0); break; @@ -205,6 +216,28 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, return -EINVAL; } + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { + case SND_SOC_DAIFMT_RIGHT_J: + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_RCR_REG, + DAVINCI_MCBSP_RCR_RFRLEN1(1) | + DAVINCI_MCBSP_RCR_RDATDLY(0)); + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_XCR_REG, + DAVINCI_MCBSP_XCR_XFRLEN1(1) | + DAVINCI_MCBSP_XCR_XDATDLY(0) | + DAVINCI_MCBSP_XCR_XFIG); + break; + case SND_SOC_DAIFMT_I2S: + default: + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_RCR_REG, + DAVINCI_MCBSP_RCR_RFRLEN1(1) | + DAVINCI_MCBSP_RCR_RDATDLY(1)); + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_XCR_REG, + DAVINCI_MCBSP_XCR_XFRLEN1(1) | + DAVINCI_MCBSP_XCR_XDATDLY(1) | + DAVINCI_MCBSP_XCR_XFIG); + break; + } + return 0; } @@ -223,13 +256,6 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, DAVINCI_MCBSP_SPCR_RINTM(3) | DAVINCI_MCBSP_SPCR_XINTM(3) | DAVINCI_MCBSP_SPCR_FREE); - davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_RCR_REG, - DAVINCI_MCBSP_RCR_RFRLEN1(1) | - DAVINCI_MCBSP_RCR_RDATDLY(1)); - davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_XCR_REG, - DAVINCI_MCBSP_XCR_XFRLEN1(1) | - DAVINCI_MCBSP_XCR_XDATDLY(1) | - DAVINCI_MCBSP_XCR_XFIG); i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_SAMPLE_BITS); w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SRGR_REG);

4 3

[alsa-devel] Git branches with Gentoo fixes
by flameeyes＠gmail.com 13 Nov '08

13 Nov '08

Hi all, Since I have just had to fix (again) an --as-needed issues on alsa-tools on the Gentoo ebuild, I've decided to clone the git repo and see to try pushing (again, I'm sure I tried before) the Gentoo-specific patches. You can find two git branches for alsa-tools and alsa-utils at these addresses: git://git.flameeyes.eu/others/alsa/alsa-tools.git git://git.flameeyes.eu/others/alsa/alsa-utils.git For the patches coming from users, the proper Author setting was done so that they are reported coming from the correct contributor. HTH, -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/

3 12

[alsa-devel] [topic/asoc][PATCH] ASoC: OMAP: Add more supported sample rates into McBSP DAI driver
by Jarkko Nikula 13 Nov '08

13 Nov '08

Originally it was put too tight limits to support only 44.1 kHz and 48 kHz sample rates in McBSP DAI driver. Extend it now to 8 kHz - 96 kHz. With 96 kHz and 2*16 bits, bit clock is 3.072 MHz < 3.125 MHz (I2S max?). Tested on Nokia N810 with TVL320AIC33 from rates 8 - 96 kHz and on Texas Instruments Beagle with TWL4030 from rates 8 - 48 kHz. Signed-off-by: Jarkko Nikula <jarkko.nikula(a)nokia.com> Cc: Steve Sakoman <steve(a)sakoman.com> Cc: Arun KS <arunks(a)mistralsolutions.com> --- sound/soc/omap/omap-mcbsp.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 8485a8a..3d4060b 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -36,9 +36,7 @@ #include "omap-mcbsp.h" #include "omap-pcm.h" -#define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_44100 | \ - SNDRV_PCM_RATE_48000 | \ - SNDRV_PCM_RATE_KNOT) +#define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_8000_96000) struct omap_mcbsp_data { unsigned int bus_id; -- 1.5.6.5

4 3

[alsa-devel] 2.6.28-rc2-mm1 - sound semi-busted on Dell Latitude D820
by Valdis.Kletnieks＠vt.edu 13 Nov '08

13 Nov '08

Sometime between -mmotm1017 and -rc2-mm1, something odd happened to the sound subsystem. On my Dell Latitude D820, audio works OK if it's sitting there standalone, or in its docking station. However, when I plug in headphones, it goes silent. Sorry for not having any more detail, but I've not had a chance to bisect this down to a specific commit. I did run alsa-info for the two kernels, here's a diff between them. I also attached a copy of the full output for working -mmotm1017. (- lines are working -mmotm-1017, + are busted -rc2-mm1) --- alsa-info-mmotm1017 2008-11-10 14:17:04.000000000 -0500 +++ alsa-info-rc3-mm1 2008-11-10 14:13:17.000000000 -0500 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.51 !!################################ -!!Script ran on: Mon Nov 10 14:16:47 EST 2008 +!!Script ran on: Mon Nov 10 14:12:28 EST 2008 !!Linux Distribution @@ -15,7 +15,7 @@ !!Kernel Information !!------------------ -Kernel release: 2.6.27-mmotm1017 +Kernel release: 2.6.28-rc3-mm1 Operating System: GNU/Linux Architecture: x86_64 Processor: x86_64 @@ -25,7 +25,7 @@ !!ALSA Version !!------------ -Driver version: 1.0.18rc3 +Driver version: 1.0.18 Library version: 1.0.18rc3 Utilities version: 1.0.18rc3 @@ -39,7 +39,7 @@ !!----------------------------- 0 [Intel ]: HDA-Intel - HDA Intel - HDA Intel at 0xefffc000 irq 314 + HDA Intel at 0xefffc000 irq 41 !!PCI Soundcards installed in the system @@ -165,8 +165,8 @@ Pin Default 0x0321121f: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf - Pin-ctls: 0xc0: OUT HP - Unsolicited: tag=30, enabled=1 + Pin-ctls: 0x00: + Unsolicited: tag=3d, enabled=1 Connection: 1 0x0b Node 0x0e [Pin Complex] wcaps 0x400181: Stereo @@ -234,12 +234,12 @@ !!ALSA Device nodes !!----------------- Looks like it lost the bits that setup the headphone jack.

2 6