On Sun, Feb 23, 2014 at 09:41:11PM +0200, Antonis Tsolomitis wrote:
> 
> 
> 
> 
> Στις 23/02/2014 07:09 μμ, ο/η Johannes von Rotz έγραψε:
> > On 02/21/2014 09:50 AM, Antonis Tsolomitis wrote:
> >> OK. You are right. But do you see what should be done and how?
> > Good evening.
> >
> > Just for the record: I had a similar problem under CentOS 6.4 (Hm, I
> > guess I should update this box more often). When logging into CDE via
> > dtlogin, sound would not work.
> >
> > Since I don't really "get" PulseAudio, I was looking for solutions in
> > all possible directions. In the end, the issue was permission-related. I
> > added my user to the "audio" group, and after a relogin the sound works
> > as it should.
> >
> > I think the problem here is, that normally these permissions would be
> > handled by ConsoleKit, but that's another piece of software I dont "get".
> >
> > Maybe this input is useful to you.
> >
> > Cheers, J.
> >
> 
> 
> You are probably correct. But this means that one would not use pulse at
> all. (Pulse is already in the audio group
> so using pulse does not need to add users to that group). What you
> suggest is a solution for me and thank you for this.
> But I think that CDE should move forward, and something must be done
> centrally for this issue; i.e. in CDE's code.
> Unless it is decided that pulse is not the way to go for CDE.
> Pulse is already started as a service in practically all linux
> distributions. Many applications come preconfigured for pulse
> like for example Skype. So CDE can take advantage of an already
> installed, running and widely used technology.

Making sure that pulseaudio is started should NOT be part of the core code,
but part of the startup script configuration (whether part of the
initscripts or a session-specific script).
Hard-coding "start this daemon with these options" will always break
someone's system, somewhere along the line.

I suspect that pulseaudio + dtlogin works on all systems that do not
use upstart, but fails on upstart because of how upstart works.

This would mean that Fedora, Arch, or Debian would work with 
Pulseaudio and dtlogin, but not recent Ubuntu or RHEL/CentOS/SL 6.
I don't know how SuSE/OpenSuSE fall into line.

The explanation:
Upstart is purely event-based; dependencies are handled by starting on
the start of the service you want to depend on.
So if the login manager does not "emit" the right events, anything that
depends on a login manager will fail to start.
If this is the problem, the solution is to provide a native upstart service
which "emits" every event that the lightdm service emits.
This service is the /etc/init/dtlogin.conf that I said needed to be
written.


Now, back to Pulseaudio...

1. Unless an application actually outputs sound, it does not need to have
any awareness of pulseaudio, as long as the pulseaudio daemon is
started.

2. CDE does not output sound itself, and that is the *right* way for
things to be.

3. CDE is a UNIX desktop; I assume you've noticed that a bit of work
is happening on FreeBSD, NetBSD, and OpenBSD.
Besides that, there's talk about Solaris/Illumos, Darwin/OS X, and
possibly other ports; it runs on Slackware, where Pulseaudio is
optional; and Debian supports OSS4 and ALSA (with or without dmix) as well
as Pulseaudio.
(I use Debian with OSS4, myself).
And the code has several layers of

Of these platforms, the breakdown for audio APIs is about like this:
Solaris, *BSD: support some variant of OSS (AFAICT, the core layer is a 
similar approach but different API, then there's a shim.)
Darwin/OS X: Coreaudio; OpenAL on top. liboss is available.
Linux:  Drivers: ALSA, OSS3, OSS4. 
        Mixers: PulseAudio, JACK, dmix (ALSA), OSS4 vmix.
        APIs: ALSA, OSS, Pulseaudio, JACK, OpenAL.

No, Pulseaudio is not standard on all the platforms CDE supports.

If CDE were to use a single audio API, OSS would make the most sense,
with OpenAL and PortAudio (a cross-platform, MIT-licensed audio
library) as two other choices that would make sense.
(Again: I do not think CDE should do anything with audio; I don't think
sound themes are useful, daemons belong in system or user configuration,
and audio players and mixers will probably be better off shipped
independently.)

Thanks,
Isaac Dunham

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
cdesktopenv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Reply via email to