[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
important
ones I guess, are fine on both archs. On i386, all is fine, also the others I
tested.
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
there
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.
Sebastian
>
> Riccardo
>