Recording problem with ALSA: trying to set up some constraints

Recording problem with ALSA: trying to set up some constraints

[Sedji Gaouaou]

Hi,


I have a problem with my recording driver.
I have set up a pcm_hardware structure in which I define the format 
supported by my hardware:

static struct snd_pcm_hardware snd_at91_ac97_capture_hw = {
    .info            = (SNDRV_PCM_INFO_INTERLEAVED
                   | SNDRV_PCM_INFO_MMAP
                   | SNDRV_PCM_INFO_MMAP_VALID
                                   | SNDRV_PCM_INFO_BLOCK_TRANSFER),
    .formats        = (SNDRV_PCM_FMTBIT_S16_LE
                   | SNDRV_PCM_FMTBIT_S16_BE
                   | SNDRV_PCM_FMTBIT_S20_3LE
                   | SNDRV_PCM_FMTBIT_U20_3LE
                   | SNDRV_PCM_FMTBIT_S20_3BE
                   | SNDRV_PCM_FMTBIT_U20_3BE
                   | SNDRV_PCM_FMTBIT_S18_3LE
                   | SNDRV_PCM_FMTBIT_U18_3LE
                   | SNDRV_PCM_FMTBIT_S18_3BE
                   | SNDRV_PCM_FMTBIT_U18_3BE),
    .rates            = SNDRV_PCM_RATE_CONTINUOUS,
    .rate_min        = 8000,
    .rate_max        = 48000,
    .channels_min        = 1,
    .channels_max        = 2,
    .buffer_bytes_max    = 256*1024,
    .period_bytes_min    = 1024,
    .period_bytes_max    = 4*1024,
    .periods_min        = 1,
    .periods_max        = 64,
};

Then in my open function I pass it to the runtime struct.

Nevertheless if  I try to run arecord with this option: arecord -d 1 
test.wav, I will have a kernel oops.
The default format is U8, but it is not supported by my Hardware, abd it 
is not defined in my structure, so I though that it should exit arecord 
but not crash.

Do I miss something when defining my pcm_hardware strucutre, or do I 
forgot to use a specific function which should return me an error?

I have try to set up some constraints as well(for the rate and the 
format), but still I have the same crash.


Regards,
Sedji

Re: Recording problem with ALSA: trying to set up some constraints

[Clemens Ladisch]

Sedji Gaouaou wrote:
> I have a problem with my recording driver.
> I have set up a pcm_hardware structure in which I define the format
> supported by my hardware:
> ...
>     .formats        = (SNDRV_PCM_FMTBIT_S16_LE
>                    | SNDRV_PCM_FMTBIT_S16_BE
>                    | SNDRV_PCM_FMTBIT_S20_3LE
>                    ...
>
> Then in my open function I pass it to the runtime struct.
>
> Nevertheless if  I try to run arecord with this option: arecord -d 1
> test.wav, I will have a kernel oops.
> The default format is U8, but it is not supported by my Hardware, abd it
> is not defined in my structure, so I though that it should exit arecord
> but not crash.

The default device will do automatic sample format conversion, i.e.,
your driver will see a request for S16_LE.

This looks like a bug somewhere else in your driver.


Regards,
Clemens

Re: Recording problem with ALSA: trying to set up some constraints

[Sedji Gaouaou]

Clemens Ladisch a écrit :
> Sedji Gaouaou wrote:
>> I have a problem with my recording driver.
>> I have set up a pcm_hardware structure in which I define the format
>> supported by my hardware:
>> ...
>>     .formats        = (SNDRV_PCM_FMTBIT_S16_LE
>>                    | SNDRV_PCM_FMTBIT_S16_BE
>>                    | SNDRV_PCM_FMTBIT_S20_3LE
>>                    ...
>>
>> Then in my open function I pass it to the runtime struct.
>>
>> Nevertheless if  I try to run arecord with this option: arecord -d 1
>> test.wav, I will have a kernel oops.
>> The default format is U8, but it is not supported by my Hardware, abd it
>> is not defined in my structure, so I though that it should exit arecord
>> but not crash.
> 
> The default device will do automatic sample format conversion, i.e.,
> your driver will see a request for S16_LE.
> 
> This looks like a bug somewhere else in your driver.
> 
> 
> Regards,
> Clemens
> 
That means that if the format is no supported, it should not return an 
error, but just use another format which is supported?

USB Data Dropping

[Charles Eidsness]

Hi All,

I'm developing a USB DAC and I've ran into an issue that has me scratching my 
head. Every once in a while (30 seconds or so) my USB DAC gets sent a USB frame 
that's missing a few samples, unless I'm also streaming audio through my 
laptop's built-in audio interface, i.e. playing audio through my USB DAC alone 
and I get dropped data, playing audio through my USB DAC and the built-in audio 
device at the same time (unique streams to each device) and I get no dropped 
data to my USB DAC. Once I stop playing audio on the built-in device I start 
getting dropped data to my USB DAC again.

The USB DAC is using the standard USB Audio drivers, and the built-in device is 
an RealTek ALC880 HDA device connected through an Intel 82801. I'm guessing that 
the hda driver is configuring some global parameter when it's in active playback 
mode that the USB driver should maybe also be setting. Any ideas? I've already 
played around with lspci (the USB interface on my laptop is PCI based) but can't 
see any differences in PCI configuration between when I'm playing audio on the 
biult-in device and when I'm not.

Thanks!
Charles

Re: USB Data Dropping

[Charles Eidsness]

Charles Eidsness wrote:
> Hi All,
> 
> I'm developing a USB DAC and I've ran into an issue that has me scratching my 
> head. Every once in a while (30 seconds or so) my USB DAC gets sent a USB frame 
> that's missing a few samples, unless I'm also streaming audio through my 
> laptop's built-in audio interface, i.e. playing audio through my USB DAC alone 
> and I get dropped data, playing audio through my USB DAC and the built-in audio 
> device at the same time (unique streams to each device) and I get no dropped 
> data to my USB DAC. Once I stop playing audio on the built-in device I start 
> getting dropped data to my USB DAC again.
> 

I'm still not completely sure what's going on but if I turn off acpi support in 
the kernel I no longer have this issue. I guess there's some sort of unexpected 
IRQ interaction. Strangely setting acpi=noirq doesn't solve the problem so maybe 
it's related to interrupts that ACPI is throwing up. It may just be related to 
the configuration of my laptop (Acer 8104).

Cheers,
Charles