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

[alsa-devel] [PATCH 14/28] Remove MACH_SMDKC210
by Richard Weinberger 01 Mar '14

01 Mar '14

The symbol is an orphan, get rid of it. Signed-off-by: Richard Weinberger <richard(a)nod.at> --- sound/soc/samsung/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 454f41c..7ea576c 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -145,7 +145,7 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380 config SND_SOC_SAMSUNG_SMDK_WM9713 tristate "SoC AC97 Audio support for SMDK with WM9713" - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210) + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310) select SND_SOC_WM9713 select SND_SAMSUNG_AC97 help -- 1.8.4.2

3 9

[alsa-devel] [PATCH v2 00/11] ASoC: Consolidate enum controls and DAPM MUXs
by Lars-Peter Clausen 01 Mar '14

01 Mar '14

Changes since v1: * Rename the xmax parameter for the SOC_ENUM_SINGLE_VIRT() macro to xitems. Original cover letter below. We currently have 5 nearly identical implementations of enum controls. Two for normal controls and three for DAPM controls. The only difference between them is how and if the selected enum item is mapped to a register value. For normal enums there is a direct mapping of the selected item to the register value, for value enums there is an additional look-up table that maps the selected item to a register value. DAPM also as a virtual enum which is not backed by any hardware register and the enum is solely used to influence DAPM routing decisions. The different implementations can easily be consolidating by making a few small changes. The series first introduces two helper functions to translate between the selected item and the register value. These functions will do the right thing depending on whether the enum has a direct mapping or is a value enum. These functions will be used to consolidate enums and value enums as well as MUXs and value MUXs. The next step is consolidate MUXs and virtual MUXs. This requires enums that are only used as virtual enums to be marked as such. This is done the same way as for virtual mixer controls by setting reg to SND_SOC_NOPM. All users of virtual MUXs are updated accordingly and then virtual MUXs and MUXs are updated to share the same implementation. The last patch in the series does cleanup of dapm_set_path_status() on top of all this. Once this has been merged I'll send a second patch-set replacing and removing the now deprecated ENUM and MUX macros. The series depends on topic/dapm, topic/enum, topic/sign, topic/adau1373, topic/max98090, topic/mc13783, fix/wm8994, topic/wm899 Lars-Peter Clausen (11): ASoC: Remove unused 'reg2' field from soc_enum struct ASoC: Consolidate enum and value enum controls ASoC: dapm: Consolidate MUXs and value MUXs ASoC: Add macros for defining virtual enums ASoC: adau1373: Use SOC_ENUM_SINGLE_VIRT_DECL() ASoC: max98090: Use SOC_ENUM_SINGLE_VIRT_DECL() ASoC: mc13783: Use SOC_ENUM_SINGLE_VIRT_DECL() ASoC: wm8994: Use SOC_ENUM_SINGLE_VIRT_DECL() ASoC: wm8995: Use SOC_ENUM_SINGLE_VIRT_DECL() ASoC: dapm: Consolidate MUXs and virtual MUXs ASoC: dapm: Break dapm_set_path_status() appart include/sound/soc-dapm.h | 38 +---- include/sound/soc.h | 41 +++-- sound/soc/codecs/adau1373.c | 4 +- sound/soc/codecs/max98090.c | 2 +- sound/soc/codecs/mc13783.c | 6 +- sound/soc/codecs/wm8994.c | 3 +- sound/soc/codecs/wm8995.c | 2 +- sound/soc/soc-core.c | 101 ++---------- sound/soc/soc-dapm.c | 369 +++++++++----------------------------------- 9 files changed, 136 insertions(+), 430 deletions(-) -- 1.8.0

2 12

[alsa-devel] Audio passthrough on Pandaboard using ALSA API
by Vadim Izmalkov 28 Feb '14

28 Feb '14

Hello I created simple application that makes audio pass-through (from analog input to analog output), After 2-10 seconds get error like: AlsaPassthrough: pcm.c:693: snd_pcm_close: Assertion `pcm' failed. or write to audio interface failed (Broken pipe) Seems I have problem with buffer size/time or somethink like that. Parameters used: Buffer - 100 ms / 4800 frames / 19200 bytes Period - 10 ms / 480 frames / 1920 bytes Buffer length used 19200 bytes. char buffer[19200]; Write/read function used as follow snd_pcm_readi(pcm, buffer, frames); snd_pcm_writei(pcm, buffer, frames); Have somebody any suggestion? Segments of the code you can find bellow. Alsamixer settings: amixer cset name='Analog Left Capture Route' 'Headset Mic' amixer cset name='Analog Right Capture Route' 'Headset Mic' amixer cset name='MUX_UL00' 'AMic0' amixer cset name='MUX_UL01' 'AMic1' amixer cset name='Headset Left Playback' 'HS DAC' amixer cset name='Headset Right Playback' 'HS DAC' amixer cset name='Headset Playback Volume' 100 amixer cset name='DL1 Media' 120 Structure for the devices: typedef struct { char *deviceName; snd_pcm_t *pcm; snd_pcm_hw_params_t *hwParams; snd_pcm_stream_t stream; snd_pcm_access_t access; snd_pcm_format_t format; snd_pcm_uframes_t frames; int mode; unsigned int sampleRate; unsigned int bufferTime; unsigned int periodTime; unsigned int channels; } pcmDevice_t; Parameters for capture: pcmDevice_t* initRecordDevice() { pcmDevice_t *device; device = malloc(sizeof(pcmDevice_t)); device->deviceName = strdup("plughw:0,0"); device->stream = SND_PCM_STREAM_CAPTURE; device->access = SND_PCM_ACCESS_RW_INTERLEAVED; device->format = SND_PCM_FORMAT_S16_LE; device->mode = 0; //SND_PCM_ASYNC; //SND_PCM_NONBLOCK; device->sampleRate = 48000; device->bufferTime = 100 * 1000; // 100 ms device->periodTime = 10 * 1000; // 20ms device->channels = 2; return device; } Parameters for playback: pcmDevice_t* initPlaybackDevice() { pcmDevice_t *device; device = malloc(sizeof(pcmDevice_t)); device->deviceName = strdup("plughw:0,0"); device->stream = SND_PCM_STREAM_PLAYBACK; device->access = SND_PCM_ACCESS_RW_INTERLEAVED; device->format = SND_PCM_FORMAT_S16_LE; device->mode = 0; //SND_PCM_ASYNC; //SND_PCM_NONBLOCK; device->sampleRate = 48000; device->bufferTime = 100 * 1000; // 100 ms device->periodTime = 10 * 1000; // 20ms device->channels = 2; return device; } Setup devices: int setupDevice(pcmDevice_t *device) { int err; /* Open PCM. The last parameter of this function is the mode. */ /* If this is set to 0, the standard mode is used. Possible */ /* other values are SND_PCM_NONBLOCK and SND_PCM_ASYNC. */ /* If SND_PCM_NONBLOCK is used, read / write access to the */ /* PCM device will return immediately. If SND_PCM_ASYNC is */ /* specified, SIGIO will be emitted whenever a period has */ /* been completely processed by the soundcard. */ if ((err = snd_pcm_open(&device->pcm, device->deviceName, device->stream, device->mode)) < 0) { fprintf (stderr, "cannot open audio device %s (%s)\n", device->deviceName, snd_strerror (err)); exit (1); } if ((err = snd_pcm_hw_params_malloc (&device->hwParams)) < 0) { fprintf (stderr, "cannot allocate hardware parameter structure (%s)\n", snd_strerror (err)); exit (1); } if ((err = snd_pcm_hw_params_any (device->pcm, device->hwParams)) < 0) { fprintf (stderr, "cannot initialize hardware parameter structure (%s)\n", snd_strerror (err)); exit (1); } if ((err = snd_pcm_hw_params_set_access (device->pcm, device->hwParams, device->access)) < 0) { fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err)); exit (1); } if ((err = snd_pcm_hw_params_set_format (device->pcm, device->hwParams, device->format)) < 0) { fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err)); exit (1); } if ((err = snd_pcm_hw_params_set_buffer_time_near (device->pcm, device->hwParams, &device->bufferTime, NULL)) < 0) { fprintf (stderr, "cannot set buffer size (%s)\n", snd_strerror (err)); exit (1); } else { /* Set buffer size (in frames). The resulting latency is given by */ /* latency = periodsize * periods / (rate * bytes_per_frame) */ snd_pcm_hw_params_get_buffer_size(device->hwParams, &device->frames); } if ((err = snd_pcm_hw_params_set_period_time_near (device->pcm, device->hwParams, &device->periodTime, NULL)) < 0) { fprintf (stderr, "cannot set period size (%s)\n", snd_strerror (err)); exit (1); } if ((err = snd_pcm_hw_params_set_rate_near (device->pcm, device->hwParams, &device->sampleRate, NULL)) < 0) { fprintf (stderr, "cannot set sample rate (%s)\n", snd_strerror (err)); exit (1); } if ((err = snd_pcm_hw_params_set_channels (device->pcm, device->hwParams, device->channels)) < 0) { fprintf (stderr, "cannot set channel count (%s)\n", snd_strerror (err)); exit (1); } /* Apply HW parameter settings to */ /* PCM device and prepare device */ if ((err = snd_pcm_hw_params (device->pcm, device->hwParams)) < 0) { fprintf (stderr, "cannot set parameters (%s)\n", snd_strerror (err)); exit (1); } snd_pcm_hw_params_free (device->hwParams); if ((err = snd_pcm_prepare (device->pcm)) < 0) { fprintf (stderr, "cannot prepare audio interface for use (%s)\n", snd_strerror (err)); exit (1); } return 0; } Main: main (int argc, char *argv[]) { int i; int err; char buf[4800*4]; snd_pcm_t *capture_handle; snd_pcm_hw_params_t *hw_params; snd_pcm_uframes_t frames; pcmDevice_t *pcmRecord; pcmDevice_t *pcmPlayback; pcmRecord = initRecordDevice(); pcmPlayback = initPlaybackDevice(); printf("\n----------- RECORD DEVICE -----------\n"); setupDevice(pcmRecord); showConfig(pcmRecord); printf("\n---------- PLAYBACK DEVICE ----------\n"); setupDevice(pcmPlayback); showConfig(pcmPlayback); for (i = 0; i < 100; ++i) { /* Read num_frames frames from the PCM device */ /* pointed to by pcm_handle to buffer capdata. */ /* Returns the number of frames actually read. */ //if((err = snd_pcm_readi (pcmRecord->pcm, buf, pcmRecord->frames)) != pcmRecord->frames) { if((err = snd_pcm_readi (pcmRecord->pcm, buf, 480)) != 480) { fprintf (stderr, "read from audio interface failed (%s)\n", snd_strerror (err)); exit (1); } /* Write num_frames frames from buffer data to */ /* the PCM device pointed to by pcm_handle. */ /* Returns the number of frames actually written. */ if((err = snd_pcm_writei (pcmPlayback->pcm, buf, pcmRecord->frames)) != pcmRecord->frames) { fprintf (stderr, "write to audio interface failed (%s)\n", snd_strerror (err)); exit (1); } } snd_pcm_close (capture_handle); exit (0); }? Best

2 1

[alsa-devel] [alsa-plugins] [PATCH 1/1] Allow number of channels
by Corfu, ValentinX 28 Feb '14

28 Feb '14

Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [alsa-devel] Griffin FireWave stream format information
by Stefan Richter 28 Feb '14

28 Feb '14

On Feb 27 Takashi Sakamoto wrote: > Stefan or Jay, > > Could I request you to get outputs against command in this message with > FireWave? Jay already responded, but [...] > Based on this guess and according to its manual, FireWave should have 7 > entries: > $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff01ff > 0c ff bf c1 00 00 00 00 ff 00 01 90 40 02 02 01 06 06 $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff01ff response: 000: 0c ff bf c1 00 00 00 00 ff 00 01 90 40 02 02 01 ............@... response: 010: 06 06 .. > $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff02ff > 0c ff bf c1 00 00 00 00 ff 00 02 90 40 03 02 01 06 06 $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff02ff response: 000: 0c ff bf c1 00 00 00 00 ff 00 02 90 40 03 02 01 ............@... response: 010: 06 06 .. > $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff03ff > 0c ff bf c1 00 00 00 00 ff 00 03 90 40 04 02 01 06 06 $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff03ff response: 000: 0c ff bf c1 00 00 00 00 ff 00 03 90 40 05 02 01 ............@... response: 010: 06 06 .. > $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff04ff > 0c ff bf c1 00 00 00 00 ff 00 04 90 40 05 02 01 06 06 $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff04ff response: 000: 0c ff bf c1 00 00 00 00 ff 00 04 90 40 02 02 01 ............@... response: 010: 02 00 .. > (These four is for 6ch sound for usual 5.1ch surround) > $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff05ff > 0c ff bf c1 00 00 00 00 ff 00 05 90 40 02 02 01 02 06 $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff05ff response: 000: 0c ff bf c1 00 00 00 00 ff 00 05 90 40 03 02 01 ............@... response: 010: 02 00 .. > $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff06ff > 0c ff bf c1 00 00 00 00 ff 00 06 90 40 03 02 01 02 06 $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff06ff response: 000: 0c ff bf c1 00 00 00 00 ff 00 06 90 40 04 02 01 ............@... response: 010: 02 00 .. > $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff07ff > 0c ff bf c1 00 00 00 00 ff 00 07 90 40 04 02 01 02 06 $ firewire-request /dev/fw8 fcp 0x01ffbfc100000000ffff07ff response: 000: 0a ff bf c1 00 00 00 00 ff ff 07 ff ............ > (These three is for 2ch stereo sound for Dolby Pro Logic II) > > Would you please confirm these output? So this seems to be the same as from Jay's FireWave specimen. Here are results of the other requests from your subsequent mail: $ firewire-request /dev/fw8 fcp 0x01ffbfc000000000ffffffff response: 000: 0c ff bf c0 00 00 00 00 ff 00 90 40 04 02 01 06 ...........@.... response: 010: 06 . $ firewire-request /dev/fw8 fcp 0x00ffbfc100000000ff0090400202010200 response: 000: 08 ff bf c1 00 00 00 00 ff 00 90 40 02 02 01 02 ...........@.... response: 010: 00 . $ firewire-request /dev/fw8 fcp 0x00ffbfc100000000ff0090400302010200 response: 000: 08 ff bf c1 00 00 00 00 ff 00 90 40 03 02 01 02 ...........@.... response: 010: 00 . $ firewire-request /dev/fw8 fcp 0x00ffbfc100000000ff0090400402010200 response: 000: 08 ff bf c1 00 00 00 00 ff 00 90 40 04 02 01 02 ...........@.... response: 010: 00 . -- Stefan Richter -=====-====- --=- ===-- http://arcgraph.de/sr/

2 5

[alsa-devel] [PATCH v2 0/3] alsa-lib: Improve 2.1 surround support
by David Henningsson 28 Feb '14

28 Feb '14

Thanks Takashi for your encouraging review, Diff since last version is only the things you remarked about in the first patch series. > Besides that, I find it also OK to just return the channel (>= 0) or a > negative error. But it's no big matter in which form is. This one I didn't change, just because then I would just have had to change it back in the second patch anyway. David Henningsson (3): route: Allow chmap syntax for slave channels in ttable route: Select slave chmap based on ttable information conf: Allow 2.1 surround to use different number of channels src/conf/pcm/surround21.conf | 7 +- src/pcm/pcm_route.c | 323 +++++++++++++++++++++++++++++++++++++----- 2 files changed, 290 insertions(+), 40 deletions(-) -- 1.7.9.5

3 6

[alsa-devel] hda: Bug - (timing?) problem causes DP monitor to not get activated
by Daniel Martin 28 Feb '14

28 Feb '14

Hi, I'm having a bug here, where the loaded hda module causes some (timing?) problem resulting in a monitor connected to the DP not to get active. I can reproduce this on a Lenovo X201 and T410 (Ironlake) sitting on a docking station, which has a monitor (Dell U2410) connected to a DP. Steps to reproduce: 1. boot with the laptop at the docking station and the monitor plugged in 2. start the X-Server ... output on LVDS and DP is okay 3. disable the DP: xrandr --output LVDS1 --preferred --output DP1 --off ... output on LVDS - okay 4. switch to DP: xrandr --output LVDS1 --off --output DP1 --preferred ... DP _usually_ doesn't gets active, it turn off into suspend state Why I think that it is related to the hda module? If I boot a kernel without the hda module step 4 always works. When having the hda module loaded I need some luck and some iterations of step 3 and 4 to activate the monitor at the DP. I verified that the problem exists in kernel v3.13.1 and v3.14-rc4. The logs I have attached have been created on the T410 with kernel v3.14-rc4. The first alsa-info....txt has been created right after booting, the second one after step 4 failed. The kernel has been build with all alsa debug options I could find, the config is attached as well, and the kernel has been booted with drm.debug=0xe - this might be to much, but it shows pretty clear when the outputs have been switched. I hope that anyone can read something usefull - something that went wrong - out of the log files. My unexercised eye can't spot anything obvious. If more logs are necessary, I'll send them. Cheers, Daniel Martin

2 1

[alsa-devel] [PATCH] ALSA: hda - Fix registration of beep input device
by Takashi Iwai 28 Feb '14

28 Feb '14

The beep input device is registered via input_register_device(), but this is called in snd_hda_attach_beep_device() where the sound devices aren't registered yet. This leads to the binding to non-existing object, thus results in failure. And, even if the binding worked (against the PCI object), it's still racy; the input device appears before the sound objects. For fixing this, register the input device properly at dev_register ops of the codec object it's bound with. Also, call snd_hda_detach_beep_device() at dev_disconnection so that it's detached at the right timing. As a bonus, since it's called in the codec's ops, we can get rid of the further call from the other codec drivers. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_beep.c | 27 ++++++++++++++++++++------- sound/pci/hda/hda_beep.h | 5 +++++ sound/pci/hda/hda_codec.c | 7 ++++++- sound/pci/hda/hda_generic.c | 1 - sound/pci/hda/patch_conexant.c | 4 +--- 5 files changed, 32 insertions(+), 12 deletions(-) diff --git a/sound/pci/hda/hda_beep.c b/sound/pci/hda/hda_beep.c index 88bb08486f77..b9d3d0cd75c9 100644 --- a/sound/pci/hda/hda_beep.c +++ b/sound/pci/hda/hda_beep.c @@ -148,7 +148,6 @@ static int snd_hda_do_attach(struct hda_beep *beep) { struct input_dev *input_dev; struct hda_codec *codec = beep->codec; - int err; input_dev = input_allocate_device(); if (!input_dev) @@ -169,12 +168,6 @@ static int snd_hda_do_attach(struct hda_beep *beep) input_dev->dev.parent = &codec->dev; input_set_drvdata(input_dev, beep); - err = input_register_device(input_dev); - if (err < 0) { - input_free_device(input_dev); - codec_err(codec, "hda_beep: unable to register input device\n"); - return err; - } beep->dev = input_dev; return 0; } @@ -244,6 +237,26 @@ void snd_hda_detach_beep_device(struct hda_codec *codec) } EXPORT_SYMBOL_GPL(snd_hda_detach_beep_device); +int snd_hda_register_beep_device(struct hda_codec *codec) +{ + struct hda_beep *beep = codec->beep; + int err; + + if (!beep || !beep->dev) + return 0; + + err = input_register_device(beep->dev); + if (err < 0) { + codec_err(codec, "hda_beep: unable to register input device\n"); + input_free_device(beep->dev); + codec->beep = NULL; + kfree(beep); + return err; + } + return 0; +} +EXPORT_SYMBOL_GPL(snd_hda_register_beep_device); + static bool ctl_has_mute(struct snd_kcontrol *kcontrol) { struct hda_codec *codec = snd_kcontrol_chip(kcontrol); diff --git a/sound/pci/hda/hda_beep.h b/sound/pci/hda/hda_beep.h index cb88464676b6..76eb8589fb9e 100644 --- a/sound/pci/hda/hda_beep.h +++ b/sound/pci/hda/hda_beep.h @@ -45,6 +45,7 @@ struct hda_beep { int snd_hda_enable_beep_device(struct hda_codec *codec, int enable); int snd_hda_attach_beep_device(struct hda_codec *codec, int nid); void snd_hda_detach_beep_device(struct hda_codec *codec); +int snd_hda_register_beep_device(struct hda_codec *codec); #else static inline int snd_hda_attach_beep_device(struct hda_codec *codec, int nid) { @@ -53,5 +54,9 @@ static inline int snd_hda_attach_beep_device(struct hda_codec *codec, int nid) static inline void snd_hda_detach_beep_device(struct hda_codec *codec) { } +static inline int snd_hda_register_beep_device(struct hda_codec *codec) +{ + return 0; +} #endif #endif diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 6db2dbcbf4d3..555e8c771cfd 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -1379,14 +1379,19 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, static int snd_hda_codec_dev_register(struct snd_device *device) { struct hda_codec *codec = device->device_data; + int err = device_add(&codec->dev); - return device_add(&codec->dev); + if (err < 0) + return err; + snd_hda_register_beep_device(codec); + return 0; } static int snd_hda_codec_dev_disconnect(struct snd_device *device) { struct hda_codec *codec = device->device_data; + snd_hda_detach_beep_device(codec); device_del(&codec->dev); return 0; } diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 9e0609a4b2ba..16133881e967 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -5350,7 +5350,6 @@ EXPORT_SYMBOL_GPL(snd_hda_gen_init); void snd_hda_gen_free(struct hda_codec *codec) { snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_FREE); - snd_hda_detach_beep_device(codec); snd_hda_gen_spec_free(codec->spec); kfree(codec->spec); codec->spec = NULL; diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 09d6d0db2b06..1dc7e974f3b1 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -445,9 +445,7 @@ static int conexant_init(struct hda_codec *codec) static void conexant_free(struct hda_codec *codec) { - struct conexant_spec *spec = codec->spec; - snd_hda_detach_beep_device(codec); - kfree(spec); + kfree(codec->spec); } static const struct snd_kcontrol_new cxt_capture_mixers[] = { -- 1.9.0

1 1

Re: [alsa-devel] PCM rules for FireWave in speaker.c
by Clemens Ladisch 28 Feb '14

28 Feb '14

Takashi Sakamoto wrote: > Current speaker.c have a rule for PCM channels/rates below: > - 6ch PCM at 32.0/44.1kHz > - 2ch PCM at 48.0/96.0kHz The current rules in speakers.c disallow rates less than 48 kHz if there are less than six channels, and disallow two channels if the rate is less than 48 kHz. This means that the allowed parameter combinations are 2ch at 48/96 kHz, and 6ch at 32/44.1/48/96 kHz. > Recently, with Jay Fenlason's help, I got some information about its > stream format. I'll show them in the end of this message. > > As a result, I realized FireWave has stream formats below: > - 6ch PCM at 32.0/44.1/48.0/96.0kHz > - 2ch IEC 60958-3 at 32.0/44.1/48.0kHz > > Although there are no stream formats for 2ch PCM at 48.0/96.0kHz, the > driver has it. Do you know the reason? Are there any model quirks? I don't have any of the AV/C audio specifications; these rules were determined experimentally. In other words, when the sample rate is set to 48 or 96 kHz, sending a stream with two PCM channels appears to work. If you wanted to support these undocumented formats in your driver, you would have to add some kind of quirk. Regards, Clemens

2 1

[alsa-devel] [PATCH 0/2] Simplify the CODEC ASoC probe code.
by Xiubo Li 28 Feb '14

28 Feb '14

3 4