On Thu, 11 Mar 2004, M?ns Rullg?rd wrote:
I've noticed some strange things with snd_pcm_wait. My application
opens the sound device in non-blocking mode and uses snd_pcm_wait
whenever snd_pcm_writei return EAGAIN. This works fine as long as
ALSA isn't doing any resampling. However, when
hi,
Even thought the SA11xx ARM platform DMA engine has a queueing
mechanism (as you mentioned), it is not being utilized. Since we are
queueing(or starting) the next dma transfer in the interrupt context, and we
recieve this interrupt only when the previous dma transfer ends. Queueing
On Fri, 12 Mar 2004, Gupta, Kshitij wrote:
hi,
Even thought the SA11xx ARM platform DMA engine has a queueing
mechanism (as you mentioned), it is not being utilized. Since we are
queueing(or starting) the next dma transfer in the interrupt context, and we
recieve this interrupt only
hi Jaroslav,
yeah I completely agree with you. We can always queue upfront, and
then in interrupt context queue next period. But the only issue I see is
that when we queue a next period, are we sure that the middle layer has
already filled up this next period fully. Don't we have to
Jaroslav Kysela [EMAIL PROTECTED] writes:
On Thu, 11 Mar 2004, M?ns Rullg?rd wrote:
I've noticed some strange things with snd_pcm_wait. My application
opens the sound device in non-blocking mode and uses snd_pcm_wait
whenever snd_pcm_writei return EAGAIN. This works fine as long as
ALSA
On Fri, 12 Mar 2004, Gupta, Kshitij wrote:
hi Jaroslav,
yeah I completely agree with you. We can always queue upfront, and
then in interrupt context queue next period. But the only issue I see is
that when we queue a next period, are we sure that the middle layer has
already filled
hi,
No no I was asking about the transfer of data from Application to
the ring buffer (which is performed by ALSA middle layer), let me reframe
the doubt I have.
When we queue a next period to the DMA engine, we have no idea whether data
for the next period has been already filled up (
On Fri, 12 Mar 2004, Gupta, Kshitij wrote:
hi,
No no I was asking about the transfer of data from Application to
the ring buffer (which is performed by ALSA middle layer), let me reframe
the doubt I have.
When we queue a next period to the DMA engine, we have no idea whether data
hi,
:) maps almost perfectly ...thanx a lot. Only other doubt I had
was, why are we always getting underruns in case of ARM (as Russell also
pointed out that there are some cache coherency problems), but I am not able
to map cache coherency problems to the underruns we are getting. We
Hi,
I remember some time ago someone contributed link to older patch (for Alsa
0.6 or 0.9) for headset driver to be included in official Alsa.
Has anyone solved that or should I apply somewhere ?
I'd like to use bluetooth headset I've got...
The driver is in here:
On Fri, 12 Mar 2004, Gupta, Kshitij wrote:
hi,
:) maps almost perfectly ...thanx a lot. Only other doubt I had
was, why are we always getting underruns in case of ARM (as Russell also
pointed out that there are some cache coherency problems), but I am not able
to map cache coherency
Mathieu Geli wrote:
ok, what I did, is first to apply your patch to my source tree
(1.0.3rc2), clean, compile, install, and even reboot. That doesn't
output anymore the two lines urb status -104, and
usb_submit_urb: -32 but still hang after printing:
drivers/usb/core/usb.c: deregistering
Jaroslav Kysela [EMAIL PROTECTED] writes:
On Thu, 11 Mar 2004, M?ns Rullg?rd wrote:
I've noticed some strange things with snd_pcm_wait. My application
opens the sound device in non-blocking mode and uses snd_pcm_wait
whenever snd_pcm_writei return EAGAIN. This works fine as long as
ALSA
Hi,
I have installed the last kernel version and I have no more beep but I
still have sounds.(no problem under 2.4)
I tried both with the included kernel version and some previous version
but nothing change...
I have no more 'beep' slide in the mixer.(I don't have the PCM one
either, i don't
Ok, I applied your second patch, and get this dmesg output:
drivers/usb/core/usb.c: deregistering driver snd-usb-audio
ALSA /home/mathieu/alsa-driver/usb/usbaudio.c:2944: snd_usb_audio_disconnect called,
refcount = 1
ALSA /home/mathieu/alsa-driver/usb/usbaudio.c:2944: snd_usb_audio_disconnect
15 matches
Mail list logo
