ICE1724 - File descriptor in bad state when capturing

ICE1724 - File descriptor in bad state when capturing

[Pavel Hofman]

Hi,

I have most of the ESI Juli driver working, but I have hit a problem 
with the capture stream. I had to modify some ice1724.c code to allow 
redefining clock-related functions in the actual card file (Juli has a 
different clocking scheme), but all the DMA code is left intact, as well 
as the methods defining the capture stream.

The ice1724 vu-meters detect input ADC data, I can hear correct sound 
when setting the internal mixer to H/W-In. Yet, when trying to record, I get

arecord -v -D hw:0,0,0 -r 44100 -f S32_LE -c2

....
RIFF$WAVEfmt  ... data arecord: pcm_read:1346: read error: File 
descriptor in bad state

At the same time, my second Envy24-based card Prodigy192 (uses the 
original methods in ice1724.c) works OK, arecord gives no errors. 
Swapping the cards using the model parameter (to swap the 
/dev/snd/pcmCXDXc device file) makes no difference.

Thank you for any hints of where I should focus my attention to. I am 
not attaching the patches, as they are rather complicated. If you find 
that important, I will send the preliminary version.


Pavel Hofman.

Re: ICE1724 - File descriptor in bad state when capturing

[Takashi Iwai]

At Sun, 09 Mar 2008 23:56:01 +0100,
Pavel Hofman wrote:
> 
> Hi,
> 
> I have most of the ESI Juli driver working, but I have hit a problem 
> with the capture stream. I had to modify some ice1724.c code to allow 
> redefining clock-related functions in the actual card file (Juli has a 
> different clocking scheme), but all the DMA code is left intact, as well 
> as the methods defining the capture stream.
> 
> The ice1724 vu-meters detect input ADC data, I can hear correct sound 
> when setting the internal mixer to H/W-In. Yet, when trying to record, I get
> 
> arecord -v -D hw:0,0,0 -r 44100 -f S32_LE -c2
> 
> ....
> RIFF$WAVEfmt  ... data arecord: pcm_read:1346: read error: File 
> descriptor in bad state

It's -EBADFD and indicates that the PCM state isn't the expected one,
in this case, SNDRV_PCM_STATE_PREPARED or RUNNING.
The error comes from snd_pcm_capture_ioctl1() in core/pcm_native.c.
Not sure what is broken, but this should be the starting point.


Takashi

Re: ICE1724 - File descriptor in bad state when capturing

[Pavel Hofman]

Takashi Iwai wrote:
> At Sun, 09 Mar 2008 23:56:01 +0100,
> Pavel Hofman wrote:
>> Hi,
>>
>> I have most of the ESI Juli driver working, but I have hit a problem 
>> with the capture stream. I had to modify some ice1724.c code to allow 
>> redefining clock-related functions in the actual card file (Juli has a 
>> different clocking scheme), but all the DMA code is left intact, as well 
>> as the methods defining the capture stream.
>>
>> The ice1724 vu-meters detect input ADC data, I can hear correct sound 
>> when setting the internal mixer to H/W-In. Yet, when trying to record, I get
>>
>> arecord -v -D hw:0,0,0 -r 44100 -f S32_LE -c2
>>
>> ....
>> RIFF$WAVEfmt  ... data arecord: pcm_read:1346: read error: File 
>> descriptor in bad state
> 
> It's -EBADFD and indicates that the PCM state isn't the expected one,
> in this case, SNDRV_PCM_STATE_PREPARED or RUNNING.
> The error comes from snd_pcm_capture_ioctl1() in core/pcm_native.c.
> Not sure what is broken, but this should be the starting point.
> 
> 
> Takashi

Takashi,

Thanks for the hint. I have found the following:

For the working capture (spdif input in my case), the function 
snd_pcm_lib_read1 gets called first with SNDRV_PCM_STATE_PREPARED, and 
consequently repeatedly with SNDRV_PCM_STATE_RUNNING.

strace arecord :
...
write(1, "data\0\0\0\200", 8data)           = 8
ioctl(4, 0x800c4151, 0xbfbf5310)        = 0
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
16384) = 16384
ioctl(4, 0x800c4151, 0xbfbf5310)        = 0
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
16384) = 16384
...

Whereas for the broken analog input, the sequence is

1. snd_pcm_lib_read1 with SNDRV_PCM_STATE_PREPARED - returns 0
2. snd_pcm_lib_read1 with SNDRV_PCM_STATE_SETUP - returns -EBADFD

strace arecord:

write(1, "data\0\0\0\200", 8data)           = 8
ioctl(4, 0x800c4151, 0xbfa6cff0)        = 0
poll([{fd=4, events=POLLIN|POLLERR|POLLNVAL, revents=POLLIN|POLLERR}], 
1, 1000) = 1
ioctl(4, 0x800c4151, 0xbfa6cff0)        = -1 EBADFD (File descriptor in 
bad state)
write(2, "arecord: pcm_read:1346: ", 24arecord: pcm_read:1346: ) = 24

The broken input falls to polling - is it somehow blocked?

Thanks a lot for further hints.

Pavel.

Re: ICE1724 - File descriptor in bad state when capturing

[Clemens Ladisch]

Pavel Hofman wrote:
> Whereas for the broken analog input, the sequence is
>
> 1. snd_pcm_lib_read1 with SNDRV_PCM_STATE_PREPARED - returns 0
> 2. snd_pcm_lib_read1 with SNDRV_PCM_STATE_SETUP - returns -EBADFD

I'd guess that your trigger callback fails somehow, bit this is
hard to determine without the source code.


Regards,
Clemens

Re: ICE1724 - File descriptor in bad state when capturing

[Pavel Hofman]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Clemens Ladisch wrote:
> Pavel Hofman wrote:
>> Whereas for the broken analog input, the sequence is
>>
>> 1. snd_pcm_lib_read1 with SNDRV_PCM_STATE_PREPARED - returns 0
>> 2. snd_pcm_lib_read1 with SNDRV_PCM_STATE_SETUP - returns -EBADFD
> 
> I'd guess that your trigger callback fails somehow, bit this is
> hard to determine without the source code.

Thanks, I will do more testing in the evening. Just in case, I am
including the relevant files. I moved all rate-relevant stuff to
card-specific routines, redefined in juli.c. The trigger code was not
changed at all.

Perhaps those new snd_pcm_hardware structs in juli.c (I do not know the
exact meaning of the _bytes_ ones)?

Thanks a lot.

Pavel.


[-- Attachment #2: juli.zip --]
[-- Type: application/zip, Size: 26833 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ICE1724 - File descriptor in bad state when capturing

[Clemens Ladisch]

Pavel Hofman wrote:
> Clemens Ladisch wrote:
> > Pavel Hofman wrote:
> > > Whereas for the broken analog input, the sequence is
> > >
> > > 1. snd_pcm_lib_read1 with SNDRV_PCM_STATE_PREPARED - returns 0
> > > 2. snd_pcm_lib_read1 with SNDRV_PCM_STATE_SETUP - returns -EBADFD
> >
> > I'd guess that your trigger callback fails somehow, bit this is
> > hard to determine without the source code.
>
> Thanks, I will do more testing in the evening. Just in case, I am
> including the relevant files. I moved all rate-relevant stuff to
> card-specific routines, redefined in juli.c. The trigger code was not
> changed at all.
>
> Perhaps those new snd_pcm_hardware structs in juli.c (I do not know the
> exact meaning of the _bytes_ ones)?

These values are in bytes (and not in frames).

It's possible that the AK4114 code stops the stream because it thinks
that the input sample rate has changed.  Try uncommenting the printk
in i2c/other/ak4114.c.


Regards,
Clemens

Re: ICE1724 - File descriptor in bad state when capturing

[Pavel Hofman]

Clemens Ladisch napsal(a):
> Pavel Hofman wrote:
>> Clemens Ladisch wrote:
>>> Pavel Hofman wrote:
>>>> Whereas for the broken analog input, the sequence is
>>>>
>>>> 1. snd_pcm_lib_read1 with SNDRV_PCM_STATE_PREPARED - returns 0
>>>> 2. snd_pcm_lib_read1 with SNDRV_PCM_STATE_SETUP - returns -EBADFD
>>> I'd guess that your trigger callback fails somehow, bit this is
>>> hard to determine without the source code.
>> Thanks, I will do more testing in the evening. Just in case, I am
>> including the relevant files. I moved all rate-relevant stuff to
>> card-specific routines, redefined in juli.c. The trigger code was not
>> changed at all.
>>
>> Perhaps those new snd_pcm_hardware structs in juli.c (I do not know the
>> exact meaning of the _bytes_ ones)?
> 
> These values are in bytes (and not in frames).
> 
> It's possible that the AK4114 code stops the stream because it thinks
> that the input sample rate has changed.  Try uncommenting the printk
> in i2c/other/ak4114.c.

Thanks, I will try that. I can even check with the whole AK4114 creation 
code commented out.

Would the SPDIF receiver code stop the analog capture stream too? The 
digital capture stream works fine.

Thanks,

Pavel.
> 
> 
> Regards,
> Clemens
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
-----------------

inSITE, s.r.o.

Kafkova 16, 160 00 Praha 6
Rubesova 29, 326 00 Plzen

Tel., fax: +420 - 37 - 74 493 58
GSM: +420 - 603 - 163 973
Email: pavel.hofman@insite.cz

www.educity.cz, www.insite.cz
www.meetings.cz, www.hrzive.cz
www.comben.cz, www.hr-online.cz
-------------------------------
Navstivte www.educity.cz, server
s nejvetsi nabidkou profesniho
vzdelavani na ceskem internetu.

Re: ICE1724 - File descriptor in bad state when capturing

[Pavel Hofman]

Clemens Ladisch wrote:
> Pavel Hofman wrote:
>> Clemens Ladisch wrote:
>>> Pavel Hofman wrote:
>>>> Whereas for the broken analog input, the sequence is
>>>>
>>>> 1. snd_pcm_lib_read1 with SNDRV_PCM_STATE_PREPARED - returns 0
>>>> 2. snd_pcm_lib_read1 with SNDRV_PCM_STATE_SETUP - returns -EBADFD
>>> I'd guess that your trigger callback fails somehow, bit this is
>>> hard to determine without the source code.
>> Thanks, I will do more testing in the evening. Just in case, I am
>> including the relevant files. I moved all rate-relevant stuff to
>> card-specific routines, redefined in juli.c. The trigger code was not
>> changed at all.
>>
>> Perhaps those new snd_pcm_hardware structs in juli.c (I do not know the
>> exact meaning of the _bytes_ ones)?
> 
> These values are in bytes (and not in frames).
> 
> It's possible that the AK4114 code stops the stream because it thinks
> that the input sample rate has changed.  Try uncommenting the printk
> in i2c/other/ak4114.c.
> 

Clemens, you are ingenious! AK4114 was wrongly hooked to the analogue 
"ice->pcm_pro" stream instead of the digital "ice->pcm" stream. It works 
now fine, thanks a lot.

Pavel.