[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gap-dev-discuss] Cynthiune - ALSA backend

From: Sebastian Reitenbach
Subject: Re: [Gap-dev-discuss] Cynthiune - ALSA backend
Date: Wed, 30 May 2012 11:28:24 +0200
User-agent: SOGoMail 1.3.15

On Wednesday, May 30, 2012 09:42 CEST, Riccardo Mottola <address@hidden> wrote:

> Hi,
> Philippe Roussel wrote:
> > Le 29/05/2012 06:59, Philippe Roussel a écrit :
> >> Hi Riccardo,
> >>
> >> Your patch looks fine to me, you should commit it.
> >> I will test it tonight and report back.
> > I successfully tested the latest cvs version with the different sound
> > files you sent and some of my music. It looks good so far.
> That is good. It doesn't solve the problem, but I think it goes in the
> right direction.
> >
> > Looking at alsa documentation it's obvious the alsa backend is overly
> > simplistic, even if it works in most cases. The API provides functions
> > to determine what the harware is capable of for example, we could
> > probably use those to handle rare configurations. I will to propose
> > patches in the future, when I'll have more time.
> >
> Yes, I had that impression too, I looked at the alsa documentation to
> understand some parameters. I also checked around mailing lists.
> Apparently the ability to accept different sample rates is
> hardware-dependent. I got the impression though that "soft resample" 
> should fix that. I am a bit confused. How can the backend know it needs
> to resample if I open it with a different rate (that is what most code I
> found around does and that is what I tried in the fall-back call I
> implemented).
> We need to take 8bit vs 16bit in account, I'm pretty sure about that,
> this will affect potentially many backends, like the endianness change did.
> Anyway, perhaps big changes need to be done after a release.. what we
> have is still much better than before.
> On the same machine, the OSS backend works fine though. Since it is not
> real OSS, but alsa-oss emulation...
> The AO backend instead has endianness problems, MP3s play like garbage.
> MP3s need "native endianness".

Right now, I have consistent behaviour with AO and Sndio on i386 and macppc.
Both play the same set of files correctly/wrong. Ogg, MP3, FLAC, the most 
ones I guess, are fine on both archs. On i386, all is fine, also the others I 

On Macppc, I tried to change endianness for the other problematic file types,
but that did not changed anything for me :( Either I did something wrong, or 
is even more lurking, i.e. (un)signedness or alignment to most or least 
significiant bit.
At least fun stuff I can configure with Sndiod, but I did not yet got around to
test those possibilities.


> Riccardo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]