On 11 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
> Anyway, xmms-cdread needs to be fixed to always convert the data to
> native byte order, if only for the EQ to work (not that we need the xmms
> EQ :).
BTW...I didn't realise before, but my EQ was enabled in xmms, which was
what was producing t
On 11 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
> Or check out the CVS tree at
> :pserver:[EMAIL PROTECTED]:/cvsroot/alsa
Will do :-)
> You're right that it doesn't have any byte-swapping code, but it marks
> the data as little endian, so apparently the OSS output plugin swaps the
> bytes (no
On Mon, 2002-03-11 at 18:38, Christopher C. Chimelis wrote:
>
> On Mon, 11 Mar 2002 [EMAIL PROTECTED] wrote:
>
> > I'm not sure it's worth hacking much in the horrible mess that is
> > the current dmasound_pmac. 2.5 is bringing the Alsa driver in which
> > has already been split, I'm wondering if
On Mon, 11 Mar 2002 [EMAIL PROTECTED] wrote:
> I'm not sure it's worth hacking much in the horrible mess that is
> the current dmasound_pmac. 2.5 is bringing the Alsa driver in which
> has already been split, I'm wondering if we shouldn't go the same
> way for what remains of 2.4 lifetime and spl
>Ah, thanks.
>
>> I'm wondering though if the problem could be fifo ping pong between
>> Keylargo and the sound chip, eventually the sound clock provided by
>> KL could be wrong. There are some bits in KeyLargo FCR 1 that can
>> control the clock fed to the sound chip, I'll try to see if those
>> c
On Mon, 11 Mar 2002 [EMAIL PROTECTED] wrote:
> What I have found is mostly cases where the dmasound code would
> try to write awacs registers on i2s based machines, which means
> the i2s registers could be garbaged. I'm fixing this in my tree
> along with making sure i2s is properly configured fr
>> Investigation shows that the size of fragments written to /dev/dsp seems
>> to be critical, fragments smaller than about 4096 bytes cause the looping
>> hang frequently. Fortunately, there are good games like tuxracer where
>> this can be configured. :)
>
>Interesting...
>
>> Still, benh and I s
On 11 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
> Investigation shows that the size of fragments written to /dev/dsp seems
> to be critical, fragments smaller than about 4096 bytes cause the looping
> hang frequently. Fortunately, there are good games like tuxracer where
> this can be configure
On Son, 2002-03-10 at 03:22, Christopher C. Chimelis wrote:
>
> On 10 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
>
> > Following up to myself, it does seem to be worse with higher quality
> > sound (meaning higher data volume) and more graphics intensive apps, so
> > bus saturation sounds plaus
>>I haven't tried it in a few weeks, but last time I did, I only got white
>>noise (LE audio needed to be byteswapped/swabbed). Has this changed? If
>>not, then xmms-cdread is certainly broken since the code is just not there
>>to do the swabbing.
>
>Same thing here, last time I tried, I got only
>Following up to myself, it does seem to be worse with higher quality
>sound (meaning higher data volume) and more graphics intensive apps, so
>bus saturation sounds plausible. Why did this never happen on the Pismo?
>Was the sound chip on a different bus there? Is there any way we can
>improve the
>
>On 9 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
>
>> I doubt xmms-cdread is broken at all, it works here with the OSS output
>> plugin but not with crossfade (it doesn't matter if crossfade uses the
>> OSS plugin or its own OSS support). The xmms-cdread code also looks
>> sane, though a quick l
>That's because I've been totally unable to reproduce this. I've tried at
>least 50 times, but never could get this to happen on my Tibook.
It never happened to me neither... until 2 days ago when on wakeup, the
speakers started emitting a kind of "larsen effect" sound, quite nasty as
it was so l
On 9 Mar 2002, Michel Dänzer wrote:
> On Sam, 2002-03-09 at 23:24, Christopher C. Chimelis wrote:
> >
> > On 9 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
> >
> > > I doubt xmms-cdread is broken at all, it works here with the OSS output
> > > plugin but not with crossfade (it doesn't matter if cro
On Son, 2002-03-10 at 05:58, Derrik Pates wrote:
> On Sat, Mar 09, 2002 at 01:39:09PM +0100, Michel D?nzer wrote:
> > - tendency to skip, most notably when using APT
>
> This is something I see at times with DACA, but I am of the opinion that
> this is an IDE-related issue - not really a "bug" per
On Sat, Mar 09, 2002 at 01:39:09PM +0100, Michel D?nzer wrote:
> - tendency to skip, most notably when using APT
This is something I see at times with DACA, but I am of the opinion that
this is an IDE-related issue - not really a "bug" per se, but just
because IDE tends to be such a CPU-hog. Unles
> On Sat, 09 Mar 2002 17:24:03 -0500 (EST), "Christopher C. Chimelis"
> <[EMAIL PROTECTED]> said:
[xmms-cdread with OSS output]
c> I haven't tried it in a few weeks, but last time I did, I only got white
c> noise (LE audio needed to be byteswapped/swabbed). Has this changed? If
c> not,
On 10 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
> Following up to myself, it does seem to be worse with higher quality
> sound (meaning higher data volume) and more graphics intensive apps, so
> bus saturation sounds plausible. Why did this never happen on the Pismo?
> Was the sound chip on a d
On Sam, 2002-03-09 at 23:52, Michel Dänzer wrote:
> On Sam, 2002-03-09 at 23:24, Christopher C. Chimelis wrote:
>
> > As for the random hangs, this may be caused by high system loads and
> > happens on just about all of my machines when I saturate the bus...
>
> Again, this never happened with th
On Sam, 2002-03-09 at 22:11, Will Aoki wrote:
>
> > - some apps cause the driver to go into a weird state where all attempts
> > to play sound fail, the only remedy is to unload and reload it
>
> is easily triggered by this:
>
> --- cut here ---
> #include
> #include
>
> int main () {
> o
On Sam, 2002-03-09 at 23:24, Christopher C. Chimelis wrote:
>
> On 9 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
>
> > I doubt xmms-cdread is broken at all, it works here with the OSS output
> > plugin but not with crossfade (it doesn't matter if crossfade uses the
> > OSS plugin or its own OSS s
On 9 Mar 2002, Michel [ISO-8859-1] Dänzer wrote:
> I doubt xmms-cdread is broken at all, it works here with the OSS output
> plugin but not with crossfade (it doesn't matter if crossfade uses the
> OSS plugin or its own OSS support). The xmms-cdread code also looks
> sane, though a quick look at
On Sat, 9 Mar 2002, Will Aoki wrote:
> Not seen the first two, but the next:
>
> > - some apps cause the driver to go into a weird state where all attempts
> > to play sound fail, the only remedy is to unload and reload it
>
> is easily triggered by this:
I'll check this out...
> Another th
On Sat, Mar 09, 2002 at 01:39:09PM +0100, Michel D?nzer wrote:
[snipsnip]
> Speaking of tumbler sound, has anyone else noticed the following issues?
>
> - tendency to skip, most notably when using APT
> - random hangs (constantly repeating a short part) with SDL apps
Not seen the first two, but t
On Sam, 2002-03-09 at 06:15, Christopher C. Chimelis wrote:
>
> On Fri, 8 Mar 2002, Gordon Paynter wrote:
>
> > No, it's a "TOSHIBA DVD-ROM SD-R2002" -- a so-called combo drive.
> > (That's probably significant, but it completely slipped my mind at the
> > time. Oops.)
>
> Speaking of xmms and
On Fri, 8 Mar 2002, Gordon Paynter wrote:
> No, it's a "TOSHIBA DVD-ROM SD-R2002" -- a so-called combo drive.
> (That's probably significant, but it completely slipped my mind at the
> time. Oops.)
Speaking of xmms and xmms-cdread, does anyone have a patch to swab the
audio data? I haven't fou
On Saturday 02 March 2002 10:45, Bastien Nocera wrote:
> On Sat, 2002-03-02 at 15:11, Michel Dänzer wrote:
> > The Linux kernel CD-ROM driver doesn't support audio grabbing with
> > all drives, maybe you need to use SCSI emulation.
>
> See linuxppc-dev Michel, the drive in my iBook 500 didn't do
>
On Sat, 2002-03-02 at 15:11, Michel Dänzer wrote:
> On Mit, 2002-02-27 at 03:20, Gordon Paynter wrote:
> >
> > When I attempt to play a CD using "AudioCD Reader 0.14a", xmms cycles
> > through the track names very fast, and no sound comes out.
> >
> > I initially thought my problem might be that
On Mit, 2002-02-27 at 03:20, Gordon Paynter wrote:
>
> When I attempt to play a CD using "AudioCD Reader 0.14a", xmms cycles
> through the track names very fast, and no sound comes out.
>
> I initially thought my problem might be that /dev/cdrom is aliased to
> /dev/hdb (other pages have asserte
29 matches
Mail list logo
