February 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH TINYCOMPRESS 2/14] compress: Change compress_write() to take buffer as const void *
by Richard Fitzgerald 22 Feb '13

22 Feb '13

The input buffer to compress_write() should be const, and is better defined as void * so the caller doesn't have to cast. diff --git a/compress.c b/compress.c index 19b9366..ee11988 100644 --- a/compress.c +++ b/compress.c @@ -299,11 +299,12 @@ int compress_get_tstamp(struct compress *compress, return 0; } -int compress_write(struct compress *compress, char *buf, unsigned int size) +int compress_write(struct compress *compress, const void *buf, unsigned int size) { struct snd_compr_avail avail; struct pollfd fds; int to_write, written, total = 0, ret; + const char* cbuf = buf; if (!(compress->flags & COMPRESS_IN)) return oops(compress, -EINVAL, "Invalid flag set"); @@ -343,12 +344,12 @@ int compress_write(struct compress *compress, char *buf, unsigned int size) to_write = avail.avail; else to_write = size; - written = write(compress->fd, buf, to_write); + written = write(compress->fd, cbuf, to_write); if (written < 0) return oops(compress, errno, "write failed!\n"); size -= written; - buf += written; + cbuf += written; total += written; } return total; diff --git a/include/tinycompress/tinycompress.h b/include/tinycompress/tinycompress.h index 8a98527..e285bd4 100644 --- a/include/tinycompress/tinycompress.h +++ b/include/tinycompress/tinycompress.h @@ -125,7 +125,7 @@ int compress_get_tstamp(struct compress *compress, * @buf: pointer to data * @size: number of bytes to be written */ -int compress_write(struct compress *compress, char *buf, unsigned int size); +int compress_write(struct compress *compress, const void *buf, unsigned int size); /* * compress_read: read data from the compress stream -- 1.7.2.5

1 1

[alsa-devel] [PATCH] Fix regression in emu1010 firmware loading
by Mihail Zenkov 22 Feb '13

22 Feb '13

This patch fix regression in emu1010 firmware loading after http://git.alsa-project.org/?p=alsa-kprivate.git;a=commitdiff;h=b209c4dfcd9… I just revert small part of this commit. Tested on emu1212m pci.

2 3

[alsa-devel] Axago ADA-X5
by Pavol Lajciak 22 Feb '13

22 Feb '13

Hello. I have USB connected Axago ADA-X5 http://www.axago.eu/cz/produkty/usb-adaptery/ADA-X5.html Chipset CMedia CM6206. Chipset is incorrectly detected as CM106. I have connected this device to speakers by optical toslik (spdif) connection. I hear in equal interval (period) reapeated jitter, when sound is playing. I use Advanced Linux Sound Architecture Driver Version 1.0.24. and Ubuntu 12.04.2 Here is ID of device - incorrectly detected chipset. Bus 002 Device 004: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device S úctou Pavol Lajčiak

1 0

[alsa-devel] [PATCH] ALSA: hda - hdmi: Make jacks phantom, if they're not detectable
by David Henningsson 22 Feb '13

22 Feb '13

Just as for analog codecs, a jack that isn't suitable for detection (in this case, NO_PRESENCE was set) should be a phantom Jack instead of a normal one. Thanks to Raymond Yau for spotting. Cc: stable(a)vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/961286 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 21425fb..78e1827 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1640,6 +1640,9 @@ static int generic_hdmi_build_jack(struct hda_codec *codec, int pin_idx) if (pcmdev > 0) sprintf(hdmi_str + strlen(hdmi_str), ",pcm=%d", pcmdev); + if (!is_jack_detectable(codec, per_pin->pin_nid)) + strncat(hdmi_str, " Phantom", + sizeof(hdmi_str) - strlen(hdmi_str) - 1); return snd_hda_jack_add_kctl(codec, per_pin->pin_nid, hdmi_str, 0); } -- 1.7.9.5

2 1

Re: [alsa-devel] [PATCH] ALSA: usb: Fix Processing Unit Descriptor parsers
by Takashi Iwai 21 Feb '13

21 Feb '13

At Thu, 21 Feb 2013 01:55:50 +0000, Pawel Moll wrote: > > Commit 99fc86450c439039d2ef88d06b222fd51a779176 "ALSA: usb-mixer: > parse descriptors with structs" introduced a set of useful parsers > for descriptors. Unfortunately the parses for the Processing Unit > Descriptor came with a very subtle bug... > > Functions uac_processing_unit_iProcessing() and > uac_processing_unit_specific() were indexing the baSourceID array > forgetting the fields before the iProcessing and process-specific > descriptors. > > The problem was observed with Sound Blaster Extigy mixer, > where nNrModes in Up/Down-mix Processing Unit Descriptor > was accessed at offset 10 of the descriptor (value 0) > instead of offset 15 (value 7). In result the resulting > control had interesting limit values: > > Simple mixer control 'Channel Routing Mode Select',0 > Capabilities: volume volume-joined penum > Playback channels: Mono > Capture channels: Mono > Limits: 0 - -1 > Mono: -1 [100%] > > Fixed by starting from the bmControls, which was calculated > correctly, instead of baSourceID. > > Now the mentioned control is fine: > > Simple mixer control 'Channel Routing Mode Select',0 > Capabilities: volume volume-joined penum > Playback channels: Mono > Capture channels: Mono > Limits: 0 - 6 > Mono: 0 [0%] > > Signed-off-by: Pawel Moll <mail(a)pawelmoll.com> > --- > include/uapi/linux/usb/audio.h | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/include/uapi/linux/usb/audio.h b/include/uapi/linux/usb/audio.h > index ac90037..d2314be 100644 > --- a/include/uapi/linux/usb/audio.h > +++ b/include/uapi/linux/usb/audio.h > @@ -384,14 +384,16 @@ static inline __u8 uac_processing_unit_iProcessing(struct uac_processing_unit_de > int protocol) > { > __u8 control_size = uac_processing_unit_bControlSize(desc, protocol); > - return desc->baSourceID[desc->bNrInPins + control_size]; > + return *(uac_processing_unit_bmControls(desc, protocol) > + + control_size); > } > > static inline __u8 *uac_processing_unit_specific(struct uac_processing_unit_descriptor *desc, > int protocol) > { > __u8 control_size = uac_processing_unit_bControlSize(desc, protocol); > - return &desc->baSourceID[desc->bNrInPins + control_size + 1]; > + return uac_processing_unit_bmControls(desc, protocol) > + + control_size + 1; > } Looks good to me. An alternative would be to change uac_processing_unit_bControlSize() to correct the header size, but I don't think it's good, as bControlSize fields in other units show the value including the header size. Daniel, what do you think? thanks, Takashi

2 2

[alsa-devel] [PATCH 1/4] compress: make variable 'running' as unsigned
by Vinod Koul 21 Feb '13

21 Feb '13

as we never expect this to be negative Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- compress.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/compress.c b/compress.c index 19d618a..a8964f4 100644 --- a/compress.c +++ b/compress.c @@ -83,7 +83,7 @@ struct compress { __u64 buffer_size; char error[COMPR_ERR_MAX]; struct compr_config *config; - int running:1; + unsigned int running:1; }; static int oops(struct compress *compress, int e, const char *fmt, ...) -- 1.7.0.4

1 4

[alsa-devel] [PATCH RFC 000/112] HD-audio generic parser improvements
by Takashi Iwai 21 Feb '13

21 Feb '13

Hi, this is a large series of patches to implement the really generic HD-audio codec parser usable for various codecs. It's based on the Realtek codec parser, so I started hacking patch_realtek.c for more generalization and improvements. Then it's merged to the existing generic parser code, hda_generic.c, and let Realtek parser just uses this new parser code. In the end, patch_realtek.c contains only the device specific fixups and the call of generic parser functions. The series contains a few improvements in the HD-audio core code, some of which aren't really dependent on the generic parser code. They are just there as I've developed this for a couple of weeks. After this patchset, most of other codecs can be migrated as well. Currently analog, ca0110, cirrus, cmedia, conexant and via codecs have been already rewritten (i.e. the own parser codes dropped). patch_sigmatel.c is still not converted yet, but can be done soon later. I'm going to send the conversion patches for these codecs right after this series. I don't expect to merge all conversions of codec parsers in 3.9 kernel, but at least, the conversion of Realtek and this generic parser code addition can be merged to 3.9. Maybe minor and easy ones like ca0110 and cmedia can be merged as well. Takashi

5 122

[alsa-devel] Discovery of device characteristics
by Tim Hewett 21 Feb '13

21 Feb '13

I'm writing software looking to discover the available sample rates, channel formats etc. for a device. I have been taking the approach of testing a sample rate from a list of potential rates, then setting the device to that rate to then test the channel formats etc.. The structure is initialised using snd_pcm_hw_params_any() then snd_pcm_hw_params_test_rate() is called for a set of rates followed by snd_pcm_hw_params_set_rate() if the previous call is successful, then snd_pcm_hw_params_test_format() for a set of formats followed by snd_pcm_hw_params_set_format() if that is successful, then snd_pcm_hw_params_test_channels(), the point being to narrow down the characteristics available for given sample rates and channel formats. For example I have a device which supports up to 8 channels at sample rates of 44.1kHz and 48kHz but only 2 channels at 96kHz. It works ok usually but keeps failing to detect that the device supports 24-bit channel formats, both for SND_PCM_FORMAT_S24_LE/BE and SND_PCM_FORMAT_S24_3LE/3BE. It detects the 16-bit formats without any problem. Online source taken from http://download.atmark-techno.com/misc/demos/usb-audio-a500-howto/hw_params… does detect the 24-bit format but doesn't set the sample rate first - each characteristic is tested in isolation - snd_pcm_hw_params_any() is called before each one. I am wondering if my way is not the correct way to determine device characteristics.

2 3

Re: [alsa-devel] HD-audio generic parser merged to linux-next (desktop with internal speaker)
by Raymond Yau 21 Feb '13

21 Feb '13

> > > > > > > > hda-emu codecs/alc662-intel-d945gclf2 > > > > > > But it's irrelevant from whether you enable independent HP mode or > > > not. It's just the policy of badness evaluation. It's possible to > > > have a different result by adjusting the badness parameters. > > > > IOW, the patch like below will make surrounds back for the device, > > for the cost of losing individual headphone volume control. > > > > It seems that it would make more sense for having surrounds for such > > desktop setups, and the patch doesn't appear to affect too severely. > > Only ALC662/663 and one CMI9880 configs have been changed by this, and > > all look reasonable. So I'm going to apply it. > > BTW, I should mention beforehand that the previous patch won't suffice > for the device like ThinkCenter A58 where the headphone can't be > shared with the primary DAC. For allowing the surrounds on such > machines, we need to implement more complex workaround (i.e. make > surrounds exclusive, and turn off others while using surrounds). http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/de… Realtek ALC662* codec for 2+2ch (multi-streaming) Intel® High Definition Audio (Intel® HD Audio): Front panel microphone/headphone header S/PDIF digital audio header Internal mono speaker header https://launchpadlibrarian.net/92117241/Card0.Codecs.codec.0.txt The result of hda-emu seem OK for ThinkCenter M55 (AD1988) which have volume controls for the internal speaker https://bugzilla.redhat.com/attachment.cgi?id=335481 But have same problem with those 6-channel HDA codec M57/M57P(AD1882) https://launchpadlibrarian.net/63326460/Card0.Codecs.codec.2.txt

1 0

[alsa-devel] [PATCH v2 0/8] Add support for directly setting the FLL REFCLK
by Charles Keepax 20 Feb '13

20 Feb '13

This patch series adds support for specifying the source of REFCLK directly for Wolfson Arizona based devices. This should allow for improved performance by using the highest available REFCLK source. Should the REFCLK source not be directly specified then the patches will default to the older behaviour of using the 32kHz clock for REFCLK. REFCLK is configured using a call to snd_soc_codec_set_pll specifying one of the new WM51xx_FLLx_REFCLK defines as the pll_id. It is valid to clear the SYNCCLK source by setting the source to ARIZONA_FLL_SRC_NONE, however once a REFCLK source it can only be replaced with another valid REFCLK source. Charles Keepax (8): ASoC: arizona: Move selection of FLL REFCLK into init ASoC: arizona: Tidy up SYNCCLK selection and cache values ASoC: arizona: Factor out check for enabled FLL ASoC: arizona: Factor out FLL disable ASoC: arizona: Factor out FLL enable ASoC: arizona: Improve suppression of noop FLL updates ASoC: arizona: Add support for directly setting the FLL REFCLK ASoC: arizona: Add convience define for clearing SYNCCLK sound/soc/codecs/arizona.c | 191 ++++++++++++++++++++++++++++++-------------- sound/soc/codecs/arizona.h | 9 ++- sound/soc/codecs/wm5102.c | 6 ++ sound/soc/codecs/wm5102.h | 6 +- sound/soc/codecs/wm5110.c | 6 ++ sound/soc/codecs/wm5110.h | 6 +- 6 files changed, 158 insertions(+), 66 deletions(-) -- 1.7.2.5

2 9