At Fri, 06 Feb 2004 20:05:42 +,
James Courtier-Dutton wrote:
>
> Takashi Iwai wrote:
> > At Thu, 05 Feb 2004 22:28:03 +,
> > James Courtier-Dutton wrote:
> >
> >>I checked out a new anonymouse cvs of alsa-driver/alsa-kernel, applied
> >>your patch, and attach the output from doing modpro
Takashi Iwai wrote:
At Thu, 05 Feb 2004 22:28:03 +,
James Courtier-Dutton wrote:
I checked out a new anonymouse cvs of alsa-driver/alsa-kernel, applied
your patch, and attach the output from doing modprobe snd-intel8x0.
I can only see printf's in the patch, so I don't see how it could have
f
At Thu, 05 Feb 2004 22:28:03 +,
James Courtier-Dutton wrote:
>
> I checked out a new anonymouse cvs of alsa-driver/alsa-kernel, applied
> your patch, and attach the output from doing modprobe snd-intel8x0.
>
> I can only see printf's in the patch, so I don't see how it could have
> fixes th
Takashi Iwai wrote:
At Wed, 04 Feb 2004 23:03:50 +,
James Courtier-Dutton wrote:
Takashi Iwai wrote:
At Mon, 02 Feb 2004 19:42:37 +,
James Courtier-Dutton wrote:
Once thing I have noticed, is that with the alc650, we used to have VRA
(alsa 0.9.8), but the 1.0.2 intel8x0 driver ignores th
Jaroslav Kysela wrote:
On Thu, 5 Feb 2004, Glenn Maynard wrote:
On Thu, Feb 05, 2004 at 12:01:28PM +0100, Jaroslav Kysela wrote:
My point is, I don't think setting start_threshold to buffer_size is
even "wrong" at all. Some people might want the buffer to be full before
it starts, and my patch
On Thu, Feb 05, 2004 at 08:38:23PM +0100, Jaroslav Kysela wrote:
> > Otherwise, programs will work on some hardware and not others, which is
> > a case that should be minimized as much as possible; it's these kinds
> > of subtle differences that make it very hard to write reliable (sound,
> > video
At Wed, 04 Feb 2004 23:03:50 +,
James Courtier-Dutton wrote:
>
> One thing that is good though, is this allowed me to do lots of testing
> for people that have codecs with fixed rates. If you do get my alc650
> codec working again with variable rates, please make sure there is some
> sort o
At Wed, 04 Feb 2004 23:03:50 +,
James Courtier-Dutton wrote:
>
> Takashi Iwai wrote:
> > At Mon, 02 Feb 2004 19:42:37 +,
> > James Courtier-Dutton wrote:
> >
> >>Once thing I have noticed, is that with the alc650, we used to have VRA
> >>(alsa 0.9.8), but the 1.0.2 intel8x0 driver ignore
On Thu, 5 Feb 2004, Glenn Maynard wrote:
> On Thu, Feb 05, 2004 at 12:01:28PM +0100, Jaroslav Kysela wrote:
> > > My point is, I don't think setting start_threshold to buffer_size is
> > > even "wrong" at all. Some people might want the buffer to be full before
> > > it starts, and my patch allo
At Thu, 5 Feb 2004 14:15:22 -0500,
Glenn Maynard wrote:
>
> On Thu, Feb 05, 2004 at 12:01:28PM +0100, Jaroslav Kysela wrote:
> > > My point is, I don't think setting start_threshold to buffer_size is
> > > even "wrong" at all. Some people might want the buffer to be full before
> > > it starts,
On Thu, Feb 05, 2004 at 12:01:28PM +0100, Jaroslav Kysela wrote:
> > My point is, I don't think setting start_threshold to buffer_size is
> > even "wrong" at all. Some people might want the buffer to be full before
> > it starts, and my patch allows for that.
>
> It's not wrong semantics. I see
On Tue, 3 Feb 2004, James Courtier-Dutton wrote:
> >>I attach a patch that fixes alsa-lib.
> >>All it does it call snd_pcm_start() just before snd_pcm_wait() and due
> >>to the if statement just above it, will only happen when the buffer is
> >>going to be filled, therefore ensuring that even if
Takashi Iwai wrote:
At Mon, 02 Feb 2004 19:42:37 +,
James Courtier-Dutton wrote:
Once thing I have noticed, is that with the alc650, we used to have VRA
(alsa 0.9.8), but the 1.0.2 intel8x0 driver ignores the VRA and fixes
itself at 48000.
yes, the detection of sample rate range seems broke
At Mon, 02 Feb 2004 19:42:37 +,
James Courtier-Dutton wrote:
>
> Once thing I have noticed, is that with the alc650, we used to have VRA
> (alsa 0.9.8), but the 1.0.2 intel8x0 driver ignores the VRA and fixes
> itself at 48000.
yes, the detection of sample rate range seems broken for some c
On Mon, 2 Feb 2004, James Courtier-Dutton wrote:
> James Courtier-Dutton wrote:
> >
> > Once thing I have noticed, is that with the alc650, we used to have VRA
> > (alsa 0.9.8), but the 1.0.2 intel8x0 driver ignores the VRA and fixes
> > itself at 48000.
> > So, before I never needed the sample
Jaroslav Kysela wrote:
On Mon, 2 Feb 2004, James Courtier-Dutton wrote:
James Courtier-Dutton wrote:
Once thing I have noticed, is that with the alc650, we used to have VRA
(alsa 0.9.8), but the 1.0.2 intel8x0 driver ignores the VRA and fixes
itself at 48000.
So, before I never needed the samp
James Courtier-Dutton wrote:
Once thing I have noticed, is that with the alc650, we used to have VRA
(alsa 0.9.8), but the 1.0.2 intel8x0 driver ignores the VRA and fixes
itself at 48000.
So, before I never needed the sample rate converters, but as it now
fixes the rate at 48000, I need the samp
Takashi Iwai wrote:
At Mon, 02 Feb 2004 17:41:02 +,
James Courtier-Dutton wrote:
In alsa 0.9.8, the snd-intel8x0 worked find with my MB. An ICH5 with ALC650.
With alsa 1.0.2, I get: -
device: front -> no-sound output
device: surround40: -> Only sound on rear left, and rear right.
device: surrou
hmm, it looks like a generic problem of intel8x0 with ALC65x.
in the recent version, the detection and implementation of PCM streams
have been changed, and i guess it's broken for these codecs.
I would think the same. I told you/alsa list about oss emulation with
mmap and quake3 problem (since fir
At Mon, 02 Feb 2004 17:41:02 +,
James Courtier-Dutton wrote:
>
> In alsa 0.9.8, the snd-intel8x0 worked find with my MB. An ICH5 with ALC650.
> With alsa 1.0.2, I get: -
> device: front -> no-sound output
> device: surround40: -> Only sound on rear left, and rear right.
> device: surround51: -
20 matches
Mail list logo
