[alsa-devel] [PATCH 0/4] ALSA: Updates for the CA0132 codec
dgreid at chromium.org
Fri Mar 15 01:34:34 CET 2013
On Sun, Feb 10, 2013 at 2:57 AM, Takashi Iwai <tiwai at suse.de> wrote:
> Hi Ian,
> At Fri, 8 Feb 2013 18:31:41 -0800,
> Ian Minett wrote:
>> From: Ian Minett <ian_minett at creativelabs.com>
>> This series contains the following updates to CA0132:
>> 1: Add firmware loading for the SpeakerEQ DSP effect.
>> 2: Improve DSP transfer timeout calculations.
>> 3: Add stream and effect latency monitoring routines
>> 4: Update hp unsolicited event handler to manage queued work.
> Thanks, I took the one now but leave others. See my reply to each.
>> These were based on the latest sound.git, but please let me know if
>> they should be against sound-unstable tree instead.
> sound.git tree for-next branch would be the place to look at.
> If I start a new branch for ca0132, I'll let you know.
> But, before going further: as I already mailed you, I could get a test
> board and started testing. The result wasn't good. At the first time
> the driver loads, the DSP loading fails always. When the driver is
> reloaded after that, it's working. So, something is still pretty
I tried this today and I can't get it to work. It is failing in
snd_hda_lock_devices called from azx_load_dsp_prepare. The DSP is
loaded from ca0132_init which is called as the result of open/resume.
Both the check for open control files and attached substreams are
failing. How can that be avoided?
> I checked the code, and fixed a few overlooked things. Now I wonder
> why dma_reset() must be called at each DSP chunk load. It reallocates
> the whole buffer, and I see no reason. It seems working even if I
> comment it out. Could you clarify?
> Another thing I noticed is that I got a short burst noise at the very
> first playback. After that, the driver starts working well.
> Is it some uninitialized buffer or so?
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
More information about the Alsa-devel