headers
Clemens Ladisch | 1 Oct 2007 08:49
Gravatar

Re: about sound/core/pcm_lib.c:1997: capture read error (DMA or IRQ trouble?)

Akio wrote:
> Clemens Ladisch <cladisch <at> fastmail.net> writes:
> > Akio wrote:
> > > Clemens Ladisch <cladisch <at> fastmail.net> writes:
> > > > I would have guessed that some 32-bit counter has overflowed, but at
> > > > 48 kHz, a frame counter would overflow after slightly less than
> > > > 25 hours.
> > > 
> > > Thanks for Clemens. Could you tell me the counter's name and which layer does it?
> > > in alsa driver or in alsa lib or in alsa core module?
> > 
> > I'm not aware of any such bug in the ALSA framework.  I'd guess this is
> > some problem with your driver.
> > 
> > What sample frequency are you using?
> 
>   in my case, the sampling rate is 16k,

At 16 kHz, a 32-bit counter overflows after about 74.5 hours.

> what is the unit of the counter? period counts or samples?

I do not know what counter this could be.  I'm just guessing that _some_
counter overflows; this would fit the symptoms you've described.

> > > snd_pcm_prepare does not work.
> > 
> > What error does it return?
> 
>   I use strerr to get the error message, and it tell me "Input/Output
(Continue reading)

Permalink | Reply | 4 comments |
headers
Clemens Ladisch | 1 Oct 2007 09:07
Gravatar

Re: some alsa lib usage on arm926 platform

Akio wrote:
> 1. what is the different between "plughw:0,0", "defalut", "hw:0.0"?

"hw" goes directly to the driver, without any plugins.
"plughw" inserts sample rate and/or sample format conversion plugins if
the format requested by the application is not supported by the driver.
"default" does some additional things, depending on the driver.  On most
cards, it adds the "dmix" plugin for software mixing.

> a. the channel opened is just only one, but If I set the 
>    snd_pcm_hw_params_set_access as 
>    SND_PCM_ACCESS_RW_NONINTERLEAVED.
>    using snd_pcm_readn and snd_pcm_writen the code will not 
>    work. what is the wrong? 
>    but if set snd_pcm_hw_params_set_access as
>    SND_PCM_ACCESS_RW_INTERLEAVED
>    and using snd_pcm_readi and snd_pcm_writei. the code work 
>    very well. one channel also have data interleave problem?

INTERLEAVED is the only supported format for most stereo sound cards, so
it is the setting to be used for mono, too.

NONINTERLEAVED is only used for multichannel streams that are not
interleaved.

> b. in snd_pcm_open the block flag is set as 0. what is the mode 
>    of the operation? blocking or non-blocking? 

Blocking.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Liam Girdwood | 1 Oct 2007 12:53
Favicon

Re: ASOC: Best way to get private data from machine driver to the other drivers?

On Fri, 2007-09-28 at 16:14 -0500, Timur Tabi wrote:
> I'm writing an ASOC driver.  When my machine driver loads, it determines some 
> hardware information for the DMA controllers, some other hardware information 
> for the I2S controller, and even more information for the codec.
> 
> I want to be able to pass all this information to each of the three other 
> drivers.  Unfortunately, it doesn't appear that I have enough "private_data" 
> pointers available to me.
> 
> The current ASOC drivers all use statically defined global structures and 
> indexes into arrays of these structures to identify individual devices, such 
> associating I2S controller #2 with DMA channels 3 and 4.  On PowerPC, this 
> doesn't work.  The actual hardware configuration is determined at runtime (see 
> arch/powerpc/boot/dts/), and so the machine driver needs to collect all the 
> information and make all the device-to-device associations.
> 
> For example, the PCM driver has an open function:
> 
> static struct snd_pcm_ops fsl_dma_ops = {
> 	.open           = fsl_dma_open,
> 	...
> 
> static int fsl_dma_open(struct snd_pcm_substream *substream)
> {
> 	...
> 
> What I would like is for fsl_dma_open() to be able to obtain pointers to the 
> DMA controller's registers (there are two controllers with 4 channels each) by 
> looking inside 'substream'.  How can I do that?
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Timur Tabi | 1 Oct 2007 22:10
Favicon

Re: ASOC: Best way to get private data from machine driver to the other drivers?

Liam Girdwood wrote:

> Could you have a look at the V2 i.mx31 SSI driver and let me know if we
> need further changes for better dts support.

I'll do that.  However, I still have the same problem - without a git-http 
interface, my ability to "work with" that repository is limited.  Can you 
create a repo on kernel.org?  I have git better access to that site.

--

-- 
Timur Tabi
Linux Kernel Developer  <at>  Freescale
Permalink | Reply | 3 comments |
headers
Timur Tabi | 1 Oct 2007 23:49
Favicon

Re: ASOC: Best way to get private data from machine driver to the other drivers?

Liam Girdwood wrote:

> Could you have a look at the V2 i.mx31 SSI driver and let me know if we
> need further changes for better dts support.

I'm trying to port the CS4270 codec driver (it's easier) to ASOC v2, and I see 
that you don't have snd_pcm_rate_to_rate_bit().  Where did it go?

--

-- 
Timur Tabi
Linux Kernel Developer  <at>  Freescale
Permalink | Reply | 2 comments |
headers
Fernando Lopez-Lezcano | 2 Oct 2007 00:19
Picon

snd-hdsp & digiface

Hi... We are using both digiface and multiface interfaces here at ccrma
and we have a (small) problem of consistency in the channel numbering
because of the way they are connected. Both cards are connected
digitally to digital mixers, but in the case of the multiface the
digital channels (which would be the ones users use) are 9-16 while on
the digiface the first eight are 1-8[*].

Is there a way to change the ordering in the multiface so that the
digital interface is presented as ports 1-8 instead of 9-16? (even a
hack to the driver would be welcome) - and preferably one that does not
need the default interface to be changed from hw:0 in jack...

-- Fernando

[*] accounts are shared so any configuration you do on one machine for
1-8 will be wrong for the other where the real outputs are 9-16.
Permalink | Reply | 1 comment |
headers
James Pearson | 2 Oct 2007 11:17
Favicon

Re: alsa-driver-1.0.15rc2 build issues on RHEL4/CentOS4

James Pearson wrote:
> alsa-driver-1.0.15rc2 won't build cleanly on RHEL4/CentOS4 (2.6.9 based 
> kernel).
> 
> I've included the relevant errors below after running:
> 
> configure --with-redhat
> make -i
>  
>    Building modules, stage 2.
>    MODPOST
> *** Warning: "class_device_destroy" 
> [/tmp/alsa-driver-1.0.15rc2/pci/asihpi/snd-asihpi.ko] undefined!
> *** Warning: "ac97_bus_type" 
> [/tmp/alsa-driver-1.0.15rc2/pci/ac97/snd-ac97-codec.ko] undefined!
> *** Warning: "platform_device_alloc" 
> [/tmp/alsa-driver-1.0.15rc2/drivers/snd-portman2x4.ko] undefined!
> *** Warning: "platform_device_add" 
> [/tmp/alsa-driver-1.0.15rc2/drivers/snd-portman2x4.ko] undefined!
> *** Warning: "platform_device_put" 
> [/tmp/alsa-driver-1.0.15rc2/drivers/snd-portman2x4.ko] undefined!
> *** Warning: "platform_device_alloc" 
> [/tmp/alsa-driver-1.0.15rc2/drivers/snd-mts64.ko] undefined!
> *** Warning: "platform_device_add" 
> [/tmp/alsa-driver-1.0.15rc2/drivers/snd-mts64.ko] undefined!
> *** Warning: "platform_device_put" 
> [/tmp/alsa-driver-1.0.15rc2/drivers/snd-mts64.ko] undefined!

Setting/changing the following in kconfig-vers 'fixes' the above:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Akio | 2 Oct 2007 12:58
Picon

Re: about sound/core/pcm_lib.c:1997: capture read error (DMA or IRQ trouble?)

> >   in my case, the sampling rate is 16k,
> 
> At 16 kHz, a 32-bit counter overflows after about 74.5 hours.

so the unit is samples not frames. does snd_pcm_prepare will reset
the counter or not?

> > what is the unit of the counter? period counts or samples?
> 
> I do not know what counter this could be.  I'm just guessing that _some_
> counter overflows; this would fit the symptoms you've described.

   so I have to check out where is overflow occurred. which function should I
dive into?

> >   I use strerr to get the error message, and it tell me "Input/Output
> >   Error"
> 
> This error code is returned by the driver.  Which driver are you using?

my platform is Freescale i.mx27 TO1, the audio driver is come from Freescale.
the audio codec is Freescale PC13783. the alsa core version is 1.0.13, kernel 
version is 2.6.19.3.

Thank you very much.

Best Regards,
Akio
Permalink | Reply | 3 comments |
headers
Clemens Ladisch | 2 Oct 2007 13:23
Gravatar

Re: about sound/core/pcm_lib.c:1997: capture read error (DMA or IRQ trouble?)

Akio wrote:
> > >   in my case, the sampling rate is 16k,
> > 
> > At 16 kHz, a 32-bit counter overflows after about 74.5 hours.
> 
> so the unit is samples not frames. does snd_pcm_prepare will reset
> the counter or not?

You said that snd_pcm_prepare() returns -EIO, so I guess the driver
does not.

> so I have to check out where is overflow occurred. which function
> should I dive into?

Some function in the driver.

> > Which driver are you using?
> 
> my platform is Freescale i.mx27 TO1, the audio driver is come from Freescale.

Then I'd suggest you'd ask Freescale.

In any case I cannot help you if you don't tell me where to find the
source code of the driver.

Regards,
Clemens
Permalink | Reply | 2 comments |
headers
Akio | 2 Oct 2007 13:29
Picon

Re: some alsa lib usage on arm926 platform

> > After long time test. the test procedure is as the following steps:
> >    1. capture voice data as PCM data.
> >    2. encoded as amr-wb bit stream.
> >    3. decoded as PCM data from encoded bit stream.
> >    4. playback PCM data.
> > after 16 hours continue tests, there are some delay, about 800 
> > mili seconds.
> 
> You did not specify between what two quantities you've measured the
> delay, but I guess you mean the relative positions of the playback and
> capture devices.
> 
> The speed of the devices is determined by the hardware.  The playback
> and capture devices will run out of sync if they are not using the same
> clock.  Are the capture and playback devices on different computers?

   thank you very much. sorry, I don't write very clear. the codec loopback
   is test an arm platform. the position difference is between capture and 
   playback. when I send an 'a' speech into mic, and after 800ms, the speaker
   will playback. after 16 houres the delay is existed. but after further test,
   the delay will be reset to almost less 200ms. I'm very wondering why. 
   BTW, there are about two times snd_pcm_prepare in capture direction. 
   what does snd_pcm_prepare actually do? 
   I don't know the clock is sample rate or not. but the both direction are the
   same, 8k, 16k, etc. 

> > is there any way to reduce the delay after long time test.
> Measure the relative speed of the capture and playback devices, then
> resample accordingly (or just insert or drop a sample when needed).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane