On Sat, 2009-11-28 at 02:09 +, Ron Jensen wrote:
> I recently upgraded my debian stable (lenny) OpenAL to
> openal 1.9.563. I started getting:
>
> Inconsistency detected by ld.so: dl-close.c: 718: _dl_close: Assertion
> `map->l_init_called' failed!
>
> Some google searching led to this t
Erik Hofman wrote:
> Ron Jensen wrote:
>> Setting openal to not use pulse will not give these issues.
>
> Hm, that could be done for FlightGear. I´ve added support for using non
> default OpenAL output devices, but there's no code to use it that way
> yet. For example by using a command line opt
Ron Jensen wrote:
> Setting openal to not use pulse will not give these issues.
Hm, that could be done for FlightGear. I´ve added support for using non
default OpenAL output devices, but there's no code to use it that way
yet. For example by using a command line option or environment variable.
On Sat, 2009-11-28 at 02:23 +0100, Csaba Halász wrote:
> On Sat, Nov 28, 2009 at 1:48 AM, James Sleeman wrote:
> >
> > Also, that's double mixing for pulse applications isn't it? Seems a
> > fairly bad idea for latency and cpu on everything that goes through
> > pulse, which is, pretty well every
On Sat, Nov 28, 2009 at 1:48 AM, James Sleeman wrote:
>
> Also, that's double mixing for pulse applications isn't it? Seems a
> fairly bad idea for latency and cpu on everything that goes through
> pulse, which is, pretty well everything else except flightgear :-/
And skype and possibly flash.
I
For what it's worth, here's a backtrace of when it's hung trying to
connect to pulse...
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1 0x7125e42b in pa_threaded_mainloop_wait () from
/usr/lib/libpulse.so.0
#2 0x75af12
On 28/11/09 13:55, Csaba Halász wrote:
> I wonder if you can try any other OpenAl application and see if it has
> the same problem.
>
Gladly if you suggest one, I'm not familar with any.
--
Let Crystal Reports handle t
On Sat, Nov 28, 2009 at 1:48 AM, James Sleeman wrote:
> On 28/11/09 13:18, Csaba Halász wrote:
>>
>> FG ---> OpenAl ---> ALSA (dmix) > hardware
>> app1 > pulse ^
>> app2 --- ALSA (pulse) ---^
>>
>
> Also, that's double mixing for pulse applications isn't it? Seems
On 28/11/09 13:18, Csaba Halász wrote:
>
> FG ---> OpenAl ---> ALSA (dmix) > hardware
> app1 > pulse ^
> app2 --- ALSA (pulse) ---^
>
Also, that's double mixing for pulse applications isn't it? Seems a
fairly bad idea for latency and cpu on everything that goe
On Sat, Nov 28, 2009 at 1:40 AM, James Sleeman wrote:
> On 28/11/09 13:18, Csaba Halász wrote:
>> But have you actually tried keeping pulse running and directing openal
>> to alsa dmix?
>>
> No, it sounds really complicated to setup (I always found any monkeying
> with alsa to be a nightmare perso
On 28/11/09 13:18, Csaba Halász wrote:
> But have you actually tried keeping pulse running and directing openal
> to alsa dmix?
>
No, it sounds really complicated to setup (I always found any monkeying
with alsa to be a nightmare personally). And it kinda seems like it'd
be a lot of trouble f
On Sat, Nov 28, 2009 at 12:56 AM, James Sleeman wrote:
> Csaba Halász wrote:
>> These are two questions as I see it.
>> James wants to *use* pulse while most users would be happy to just
>> have FG work *around* pulse.
>> For this latter case, I believe an alsoftrc with alsa driver and
>> dmix/dsn
Csaba Halász wrote:
> These are two questions as I see it.
> James wants to *use* pulse while most users would be happy to just
> have FG work *around* pulse.
> For this latter case, I believe an alsoftrc with alsa driver and
> dmix/dsnoop devices should be fine.
>
I could work around pulse, by
Csaba Halász wrote:
> James wants to *use* pulse while most users would be happy to just
> have FG work *around* pulse.
I disagree. Instead, I suspect that most (Linux) users would be happy
to see FlightGear playing seamlessly through PulseAudio. And I'll
explain, why I think this is the case.
I
On Fri, Nov 27, 2009 at 1:38 PM, Nathanael Rebsch wrote:
> Erik Hofman wrote:
>> James Sleeman wrote:
>>
>>
>>> So, does anybody have the current CVS working well with pulse+alsa or
>>> pulse on it's own?
>>>
>>
> point though being, that a large amount of people are 'forced' to use it!
> and ther
Hi Erik,
Erik Hofman wrote:
> I've never been a fan of pulse audio and will never use it in the
> future. Let's face it, it's like sending OpenGL streams through a
> software renderer before handing it over to the OpenGL hardware.
Yes, let's face it: I've seen quite a lot of different approach
On Sat, Nov 28, 2009 at 12:19 AM, Erik Hofman wrote:
> Nathanael Rebsch wrote:
>
>> point though being, that a large amount of people are 'forced' to use it!
>> and therefore it aint a bad idea to know how to work with or around it!
>
> True.
>
> Erik
>
Some people have had some better success wi
Nathanael Rebsch wrote:
> point though being, that a large amount of people are 'forced' to use it!
> and therefore it aint a bad idea to know how to work with or around it!
True.
Erik
--
Let Crystal Reports handle the
James Sleeman wrote:
> On 28/11/09 01:59, Nathanael Rebsch wrote:
>>
>> enable users to load modules, see /etc/default/pulse
>>
> Doesn't appear to make a difference.
sorry, i meant /etc/default/pulseaudio, but i assume you found the file
i meant ^^
i also installed a bunch of pulseaudio module
I have edited /etc/default/pulse and made sure users are allowed to load
additional modules,
i also installed all modules i could find, and simple left .alsoftrc
state drivers=oss
i no longer need to kill pulse for it to work
(thou there was a need to restart services (which is tricky if pulse i
Erik Hofman wrote:
> James Sleeman wrote:
>
>
>> So, does anybody have the current CVS working well with pulse+alsa or
>> pulse on it's own?
>>
>
> I've never been a fan of pulse audio and will never use it in the
> future. Let's face it, it's like sending OpenGL streams through a
> soft
On 28/11/09 01:59, Nathanael Rebsch wrote:
enable users to load modules, see /etc/default/pulse
Doesn't appear to make a difference.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
tri
On 28/11/09 01:21, Erik Hofman wrote:
> I've never been a fan of pulse audio and will never use it in the
> future. Let's face it, it's like sending OpenGL streams through a
> software renderer before handing it over to the OpenGL hardware.
>
Be that as it may,
a) it's the standard audio set
James Sleeman wrote:
> On 28/11/09 01:41, Martin Spott wrote:
>
>> experience is with leaving the system-wide "drivers" setting as is -
>> which typically means to leave the declaration emtpy - and not setting
>> anything different in the private config
>>
> In this case it selects the alsa
On 28/11/09 01:41, Martin Spott wrote:
> experience is with leaving the system-wide "drivers" setting as is -
> which typically means to leave the declaration emtpy - and not setting
> anything different in the private config
In this case it selects the alsa->pulse setup with it's stuttering.
James Sleeman wrote:
> So, does anybody have the current CVS working well with pulse+alsa or
> pulse on it's own?
I don't use sound with FlightGear, but with other setups my best
experience is with leaving the system-wide "drivers" setting as is -
which typically means to leave the declaration e
James Sleeman wrote:
> So, does anybody have the current CVS working well with pulse+alsa or
> pulse on it's own?
I've never been a fan of pulse audio and will never use it in the
future. Let's face it, it's like sending OpenGL streams through a
software renderer before handing it over to the
I'm having major problems getting FG CVS to work with Ubuntu 9.10 and
Pulseaudio.
I have the standard alsa, pulseaudio from Ubuntu.
I have installed the latest openal-soft, just to be sure.
For the following contents of ~/.alsoftrc here are the results I get...
drivers=pulse
- very unreliabl
28 matches
Mail list logo
