On Fri, 12 Nov 2010, Manu Abraham wrote:
On Thu, Nov 11, 2010 at 6:04 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
On Thu, Nov 11, 2010 at 4:00 PM, Jaroslav Kysela <perex@xxxxxxxx> wrote:
On Thu, 11 Nov 2010, Manu Abraham wrote:
On Wed, Nov 10, 2010 at 11:35 PM, Jaroslav Kysela <perex@xxxxxxxx> wrote:
I adapted the whole thing to make the buffersize divided amongst the
XS2D_BUFFERS (8):
Probably yes.
I hope the mapping of the buffers is okay ? It looks thus, now ..
From information you sent me about hw privately, I think that the
period_bytes must be 4096 or multiple of this value with minumum count of
periods 8 (or multiple of 8). Otherwise you get a non-continuous memory area
(the hw uses only portion of system memory page, thus there'll be gaps). The
problem is that we have MMAP_COMPLEX mode, but no application can handle
(does not implement) this mmap mode and I'm not sure, if we can even
describe the DMA buffer size layout for this case for your specific hw.
I would use:
   Âsnd_pcm_hw_constraint_step(runtime, 0,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
                Â4096);
   Âsnd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIODS,
                 8);
And define periods_min = 8 (max to multiple 8 - choose your max limit) and
period_bytes_min to 4096 (max to multiple 4096 - choose your max limit).
Note that -EIO means that your driver does not called
snd_pcm_period_elapsed() and/or the pointer callback returns wrong position
to the audio ring buffer.
Ok, modified it, also added in code to acquire the stream, It's a bit
more complete now.
The crazy part that I do see now, is that I see an inconsistent lock
state with the hda_intel
driver which is the soundcard on my system. But I don't understand why
the locking on it
has to become inconsistent on loading this driver.
Ok, I found the reason: I was passing a single page for the
page_table, which I guess corrupted the whole stack !!
Eventually, I fixed the same. but ran into another issue ? Should
trigger not sleep or something that way ?
Currently, I see the issue as follows in the log, but if the
ops->run() callback is commented out I don't get that
weird message/error about lock states.
Now, ops->run(), ie xs2dtl_run() is called with other other streams,
such as an MPEG stream, where it doesn't
show any issues.
Any idea, why uncommenting ops->run() produces that message ? Should
trigger not sleep ? Confused ...
Trigger must be fast without any sleeping. Only fast spinlocks are
allowed. If you need sleep, just activate a tasklet and do the start job
in the tasklet or a thread.
Jaroslav
-----
Jaroslav Kysela <perex@xxxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
