Some background:
The primary use of libao here is at Xiph is in various apps that have
to know what the hardware is doing, eg, Squishyball. The problem with
plug devices like 'default' is that you could request 192kHz 24 bit
and ALSA will say 'sure!' and resample it down to 32kHz 8 bit because,
y
> Yes, I know my patch was not ideal. Thanks for fixing this bug properly, I'll
> prepare a new package for Debian soon.
Thank you! I didn't mean to sound harsh, just to the point :-)
(If anything I was annoyed at how the GDK documentation was silently
retconned after the background behavior in G
Hi folks,
I have a new 'release' of gPlanarity with a few new translations, and
a correct fix to the blank window bug. See:
http://web.mit.edu/~xiphmont/Public/gPlanarity.html
The fix for this bug suggested in this bug report (553500) is not
correct and works by accident, meaning it could also b
Package: libvorbis0a, libvorbisfile3, libvorbisenc2
Version: 1.3.1-1
We had a user stumble into #vorbis with Debian Unstable oggenc that
produced corrupt Vorbis files. Investigation revealed that he still
had an ancient libvorbisenc (.so.2.0.3) installed along with a fully
up-to-date libvorbis0a-
On Wed, Feb 3, 2010 at 9:14 PM, Morita Sho
wrote:
> I have built libao revision 16861 and installed it to /usr/local.
[...]
> This executable works properly. No noise at end of the playback.
Good. I was hoping and expecting this would work.
> I also tested with mmap by the following modificati
Morita,
I've committed a test fix for the VIA end-of-playback click problem to
xiph.org's libao SVN in revision 16861. This is using a strategy
different than the one you suggested and I'm interested to see if it
works:
svn co http://svn.xiph.org/trunk/ao -r 16861
It will build and install in /
> I have tested reproduce_libao_bug.c today, and the problem is still
> reproducible for me.
>
> Here is the kernel version.
> % uname -a
> Linux debian 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686
> GNU/Linux
>
> Here is an output of lspci -vv (whole log is attached as named lspci-v
dependency libs moved to Libs.private field in Xiph ao SVN r16845
Monty
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Patch applied in Xiph libao SVN r16844; will appear in release 1.0.0
Monty
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
libao was properly reporting the error; ogg123 was at fault for
ignoring it. Bug was fixed in ogg123 in Xiph SVN r14957
Monty
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
patch applied, upstream bug closed as of r16843. Fix will be in next
release (v1.0.0)
Monty
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
This is a libao2 bug. It is fixed in SVN, the fix will appear in teh
upcoming 1.0.0 release.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
This bug is beginning to conflate many issues.
However, the basic core problem comes down to where resampling is
happening. Powerbooks only posses a few hardware playback rates,
several offer only 48000. Something has to resample all other
playback rates to one that's actually supported. Ao con
Full agreement-- this is fixed in libao SVN and the fix will appear in
the upcoming 1.0.0 release.
Monty
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hello,
[Although I sincerely hope no one in using esound any longer...]
Libao is designed to automatically use the 'highest priority' audio
device available on a system, and esound is set to be higher priority
than OSS. It will use esound over OSS and ALSA automatically if it is
running if it ca
Your analysis is not quite correct; ALSA should absolutely not be
playing more samples than it receives regardless of period/hardware
buffer alignment. The only way this could happen is if the pipeline
is set to 'never underrun' mode and the playback cursor passes the
end of playback before a sto
A slight variant of this patch is now in libao SVN and will appear in
the 1.0.0 release.
Monty
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
17 matches
Mail list logo
