David Sankel wrote:
Have you used JACK?
AFAIK it definitely requires a pcm. You may have
used it on hardware
that supports multiopen which would explain what you
have observed.
Yes, I have used jack. I meant that it doesn't open
the sound device when it is not being used by a host application
> Have you used JACK?
>
> AFAIK it definitely requires a pcm. You may have
> used it on hardware
> that supports multiopen which would explain what you
> have observed.
Yes, I have used jack. I meant that it doesn't open
the sound device when it is not being used by a host application.
___
[EMAIL PROTECTED] [[EMAIL PROTECTED]]
wrote:
>
> >However, one small buglet. When recording from line1 (aux in the
> >current driver), the sound sometimes sounds very tinny and scratchy. I
> >can fix this by muting/unmuting the CD and adjusting the CD volume.
> >Yes, the CD slider in alsamixer.
Hello,
> ah, perhaps xmms alsa plugin doesn't care the endianess.
> if so, it's a bug of alsa output plugin.
I started hacking at the code. It looks like the xmms alsa plugin is fine
(if a bit messy). However, it looks like their mpg123 input plugin is
always output big-endian data even when
> On 11 Oct 2002, Jack O'Quin wrote:
> > Are you saying that the "snd_" prefix violates standard Linux
> > kernel rules for device driver options? Did the kernel developers
> > request this change?
Jaroslav Kysela <[EMAIL PROTECTED]> writes:
> Well, they had objections but not major to disallo
On Sun, 13 Oct 2002, James Courtier-Dutton wrote:
> Jaroslav Kysela wrote:
>
> >On Sat, 12 Oct 2002, James Courtier-Dutton wrote:
> >
> >
> >
> >>Currently, the state of play is that "snd_pcm_hw_params_can_pause ()"
> >>should not be called until one has first done the first
> >>"snd_pcm_hw_
Jaroslav Kysela wrote:
>On Sat, 12 Oct 2002, James Courtier-Dutton wrote:
>
>
>
>>Currently, the state of play is that "snd_pcm_hw_params_can_pause ()"
>>should not be called until one has first done the first
>>"snd_pcm_hw_params()"
>>
>>I start with
>>snd_pcm_hw_params_any(this->audio_fd, p
On Sat, 12 Oct 2002, James Courtier-Dutton wrote:
> Currently, the state of play is that "snd_pcm_hw_params_can_pause ()"
> should not be called until one has first done the first
> "snd_pcm_hw_params()"
>
> I start with
> snd_pcm_hw_params_any(this->audio_fd, params);
> then go about setting p
Currently, the state of play is that "snd_pcm_hw_params_can_pause ()"
should not be called until one has first done the first
"snd_pcm_hw_params()"
I start with
snd_pcm_hw_params_any(this->audio_fd, params);
then go about setting params, e.g.
snd_pcm_hw_params_set_access()
snd_pcm_hw_params_set_
On Sat, 12 Oct 2002, Tim Goetze wrote:
> it seems snd_pcm_hw_params_clear() is declared but never defined
> in current cvs.
Fixed. Thanks.
Jaroslav
-
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project http://www.a
it seems snd_pcm_hw_params_clear() is declared but never defined
in current cvs.
oss mixer and playback pcm work fine with the latest kernel modules
however.
tim
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://
On Sat, 12 Oct 2002, James Courtier-Dutton wrote:
>
> During setup of the sound card, I adjust the HW params and then save
> them to the card during the open() stage.
>
> Is there any alsa api call that can retrieve hw settings later. For
> example something like: -
> snd_pcm_get_buffersize()
Jaroslav Kysela wrote:
>
> On Sat, 12 Oct 2002, Abramo Bagnara wrote:
>
> > Jaroslav Kysela wrote:
> > >
> > >
> > > In this case, I propose to change snd_pcm_avail() to snd_pcm_hwsync()
> > > function with description: "synchronize r/w pointers with hardware".
> > > Really, after some thinking,
Jaroslav Kysela wrote:
>
>
> In this case, I propose to change snd_pcm_avail() to snd_pcm_hwsync()
> function with description: "synchronize r/w pointers with hardware".
> Really, after some thinking, the return value from snd_pcm_avail() cannot
> be used for nothing serious. I simply don't like
On Sat, 12 Oct 2002, Abramo Bagnara wrote:
> Jaroslav Kysela wrote:
> >
> > On Fri, 11 Oct 2002, Abramo Bagnara wrote:
> >
> > > I really don't understand why you've added another ioctl and another
> > > function to replicate in all PCM classes.
> > > snd_pcm_delay existence is enough to impleme
On Sat, 12 Oct 2002, Abramo Bagnara wrote:
> Jaroslav Kysela wrote:
> >
> >
> > In this case, I propose to change snd_pcm_avail() to snd_pcm_hwsync()
> > function with description: "synchronize r/w pointers with hardware".
> > Really, after some thinking, the return value from snd_pcm_avail() ca
During setup of the sound card, I adjust the HW params and then save
them to the card during the open() stage.
Is there any alsa api call that can retrieve hw settings later. For
example something like: -
snd_pcm_get_buffersize()
snd_pcm_get_periodsize()
Another problem is that snd_pcm_can_pau
On Fri, 11 Oct 2002, Abramo Bagnara wrote:
> Jaroslav Kysela wrote:
> >
> > Hi all,
> >
> > these enhancements are in CVS for PCM API:
> >
> > - added snd_pcm_avail() function - this function returns count of
> > available frames for write or read operations, the position
> > is rea
Jaroslav Kysela wrote:
>
> On Fri, 11 Oct 2002, Abramo Bagnara wrote:
>
> > I really don't understand why you've added another ioctl and another
> > function to replicate in all PCM classes.
> > snd_pcm_delay existence is enough to implement that.
> > I'm missing something?
>
> You're completely
On 11 Oct 2002, Jack O'Quin wrote:
>
> > Jack O'Quin wrote:
> > > Can someone please explain what terrible problem we're trying to solve
> > > that justifies introducing *any* breakage at all?
> >
> > > ALSA is part of the 2.5 kernel now. It is mainstream Linux software,
> > > good technology,
20 matches
Mail list logo
