[sent also to alsa-dev - maybe I missed an announcement about this?]
The jack (Jack Audio Connection Kit, cvs from around the beginning of
September) code no longer compiles with the most recent alsa cvs:
alsa_driver.c: In function `alsa_driver_set_parameters':
alsa_driver.c:403: too few argumen
..main reason for joining this list, is it ever going to be fixed? :)
Here is what i've learned about all my experiences so far with the
Inspiron 8200 and the CS4205:
My kernel right now, it works fine for a few minutes then starts playing
extremely choppy.. until I remove the module. Odd thing,
Hi Guilhem,
At Tue, 10 Sep 2002 08:29:59 -0700 (PDT),
Guilhem Tardy wrote:
>
> Hi all,
>
> I modified my previous patch for supporting a period_size (rather than
> period_bytes) constraint with Takashi's suggestion that the fields be non-zero
> for either constraint to kick in. See file in atta
At Tue, 10 Sep 2002 10:06:31 -0700 (PDT),
Guilhem Tardy wrote:
>
> > just add the constraint in open callback, such like
> >
> > int your_pcm_open(snd_pcm_substream_t *substream)
> > {
> > ...
> >
> > err = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
> >
> > I modified my previous patch for supporting a period_size (rather than
> > period_bytes) constraint with Takashi's suggestion that the fields be
> > non-zero for either constraint to kick in. See file in attachment.
> > It has worked fine on my hardware for the past few days.
>
> you don't ne
At Tue, 10 Sep 2002 09:05:14 -0700 (PDT),
Guilhem Tardy wrote:
>
> Hi all,
>
> I understand that prepare() is used to restart playout or capture from a known
> state in the driver, and wonder if it is OK to have it block until buffers
> being currently played out have completed?
>
> This came u
Hi all,
I modified my previous patch for supporting a period_size (rather than
period_bytes) constraint with Takashi's suggestion that the fields be non-zero
for either constraint to kick in. See file in attachment. It has worked fine on
my hardware for the past few days.
Guilhem.
>I understand that prepare() is used to restart playout or capture from a known
>state in the driver, and wonder if it is OK to have it block until buffers
>being currently played out have completed?
are you asking if a low level driver should do this? if so, then the
answer is no. the semantics
Hi all,
I understand that prepare() is used to restart playout or capture from a known
state in the driver, and wonder if it is OK to have it block until buffers
being currently played out have completed?
This came up because our app is experiencing -EPIPE quite often, most likely
because real-t
Jaroslav,
I am working on a conferencing application, and need to deal with audio packets
of various sizes (in sample).
> > It's software only limit for read/write transfers. The direct transfers
> > (mmap) don't take care about this limit. The idea is to avoid using very
> > small transfer chun
Takashi Iwai wrote:
> At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> Clemens Ladisch wrote:
>
The two PCM devices cannot be used at the same time anyway, so I think
creating a quirk for interface 0 which says "ignore this" could work.
Takashi, any comments?
>>>
>>>i think implementing
Hi Andreas,
At Mon, 9 Sep 2002 11:41:02 +0200,
Andreas Mohr wrote:
>
> Hi Takashi !
>
> On Mon, Sep 09, 2002 at 11:05:15AM +0200, Takashi Iwai wrote:
> > Hi Andreas,
> >
> > At Sun, 8 Sep 2002 11:16:59 +0200,
> > Andreas Mohr wrote:
> > >
> > > Hi all,
> > >
> > > I'm currently in the proces
Hi Karsten,
At Tue, 10 Sep 2002 00:47:16 +0200 (CEST),
karsten wiese wrote:
>
> hi,
>
> the curframesize member of struct snd_usb_substream
> seams not to be initialized to something different
> from 0.
oops, thanks for spotting.
fixed on cvs now.
>
> thus the code sequence
>
> subs->trans
At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
Clemens Ladisch wrote:
>
> > > The two PCM devices cannot be used at the same time anyway, so I think
> > > creating a quirk for interface 0 which says "ignore this" could work.
> > > Takashi, any comments?
> >
> > i think implementing a semaphore (or
Takashi Iwai wrote:
> is there any good text-format tool for usb descriptors except for
> humanbeing?
The /proc/asound/card?... information of snd-usb-audio ;-)
Fedor, it would be interesting to see how much got parsed with uhci.
> > There are two PCM devices, but both use the same endpoints.
>
15 matches
Mail list logo
