Menu
▾
▴
cdesktopenv-devel
|
From: Antonis T. <ant...@gm...> - 2014-02-16 22:05:21
|
If CDE starts through dtlogin immediately after reboot the sound does not work. This is because dtlogin has no instructions to start the pulse system. But what is the proper way to start the pulse system for the user? If we login to CDE with lightdm then stop lightdm, start dtlogin and login CDE the sound works. So what is the correct way to fix this? Antonis. |
|
From: Antonis T. <ant...@gm...> - 2016-06-13 07:30:16
|
On (at least) Ubuntu the login process (both lightdm and console) modifies the access rights to /dev/snd/* so that the sound devices accept sound streams with user permissions. But this does not work with dtlogin When you login with dtlogin the sound devices do not get user rights. So the sound does not work for the user. If now the command sudo setfacl -m "u:user:rw-" /dev/snd/* (1) is executed then the problem gets fixed and the user has access to the sound system. Can this be fixed somehow? Because it can not be executed by the user startup scripts since it must be run with root privileges. More than that this is not the proper way to do it. Because when you switch to console for another user login the sound devices must stop have the rights of the GUI logged in user and get the rights of the console user login. I guess lightdm does that automatically (chvt triggers the change of permissions-I guess). So can this be fixed somehow? At least, change the permissions to the next dtlogin user. Because if I execute (1) and then logout, and another user logs in then the permissions must change by another issue of (1). We have the same situation with the video devices. Unless you execute sudo setfacl -m "u:user:rw-" /dev/video* you do not get access to video (so eg skype does not work for video calls). Antonis. |
|
From: Martin E. <ett...@gm...> - 2016-06-13 07:39:33
|
Hello Antonis, On Mon, Jun 13, 2016 at 9:30 AM, Antonis Tsolomitis <ant...@gm...> wrote: > > On (at least) Ubuntu the login process (both lightdm and console) > modifies the access rights to /dev/snd/* > so that the sound devices accept sound streams with user permissions. > > But this does not work with dtlogin > When you login with dtlogin the sound devices do not get user rights. So > the sound does not work > for the user. > > If now the command > > sudo setfacl -m "u:user:rw-" > /dev/snd/* (1) > > is executed then the problem gets fixed and the user has access to the > sound system. > > Can this be fixed somehow? Because it can not be executed by the user > startup scripts since > it must be run with root privileges. This is done in /usr/dt/config/[Xstartup|Xreset] just copy over both files to /etc/dt/config, add the commands you need and restart dtlogin. Kind regards, Martin Etteldorf |
|
From: Antonis T. <ant...@gm...> - 2016-06-13 09:06:21
|
Hello Martin, thanks, I will do what you suggest, and obviously the problem will be solved. However commands such as setfacl -m "u:user:rw-" /dev/snd/* start looking very ..."internal/mysterious". Many users may feel comfortable with chmod but ...setfacl ..... god, it looks bad... so a reasonable question is whether there must be a patch or not. It looks to me that it is proper for dtlogin to set the proper rights for sound and video. So my previous email could be also considered a bug report. Permissions are not set correctly for the desktop to function on linux. Xstartup and Xreset now do include a (small) set of permissions (for /dev/$ITE), so it could be expanded for the linux arch. If it can't be fixed I will have to add a wiki page. Antonis. On 13/06/2016 10:39 πμ, Martin Etteldorf wrote: > Hello Antonis, > > > On Mon, Jun 13, 2016 at 9:30 AM, Antonis Tsolomitis > <ant...@gm...> wrote: >> On (at least) Ubuntu the login process (both lightdm and console) >> modifies the access rights to /dev/snd/* >> so that the sound devices accept sound streams with user permissions. >> >> But this does not work with dtlogin >> When you login with dtlogin the sound devices do not get user rights. So >> the sound does not work >> for the user. >> >> If now the command >> >> sudo setfacl -m "u:user:rw-" >> /dev/snd/* (1) >> >> is executed then the problem gets fixed and the user has access to the >> sound system. >> >> Can this be fixed somehow? Because it can not be executed by the user >> startup scripts since >> it must be run with root privileges. > This is done in /usr/dt/config/[Xstartup|Xreset] > just copy over both files to /etc/dt/config, add the commands you need > and restart dtlogin. > > > Kind regards, > > Martin Etteldorf > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > _______________________________________________ > cdesktopenv-devel mailing list > cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel |
|
From: Martin E. <ett...@gm...> - 2016-06-13 09:53:59
|
Hello Antonis, On Mon, Jun 13, 2016 at 11:06 AM, Antonis Tsolomitis <ant...@gm...> wrote: > so a reasonable question is whether there must be a patch or not. I don't think a patch would be a good idea, unless it covers all possible platforms and device instances. But how can we tell what device someone is actually using? Systems nowadays usually have more than one sound device. On-board analogue, on-board digital, in/out/duplex, HDMI for feeding screens with speakers, etc. If I use my (on-board) /dev/dsp4.1 as the main playback device on FreeBSD, it doesn't mean that this is the same for every FreeBSD user. Someone else might use /dev/dsp7.0 instead because they want to use the the builtin speakers of their screen, hooked up via HDMI. On top of that, the situation is different for each OS. On FreeBSD, we have for example /dev/dspX.Y, whereas Solaris has only /dev/dsp and /dev/dspX (with X and Y equal or greater than 0). Solaris also has an /dev/audio, which is completely missing on FreeBSD 10, but existed in earlier releases. Both FreeBSD and Solaris have a /dev/sndstat, but the devices are behaving differently. No idea about these things on the Linux side, but I bet they are looking different from both FreeBSD and Solaris. > If it can't be fixed I will have to add a wiki page. I think some general instructions on the Wiki would be much more useful, yes. Kind regards, Martin Etteldorf |
|
From: Antonis T. <ant...@gm...> - 2016-06-13 10:11:14
|
I understand your argument and the difficulties to fix it, but I do not understand "the rules". For example, I see patches sent through the list that are specific to OpenBSD, or to Solaris etc. So CDE does not get patched with a "common denominator" attitude. It does things differently on different platforms. I find this to be normal. What is /dev/$ITE found in Xstartup. It does not exist in any of my systems. None of them sets the ITE variable Yet, it is there. Anyway, in any case I will write a wiki page for this. But I think that sound and video in our days is so important for most users that it can not be ignored. best, Antonis. On 13/06/2016 12:53 μμ, Martin Etteldorf wrote: > Hello Antonis, > > On Mon, Jun 13, 2016 at 11:06 AM, Antonis Tsolomitis > <ant...@gm...> wrote: >> so a reasonable question is whether there must be a patch or not. > I don't think a patch would be a good idea, unless it covers all > possible platforms and > device instances. But how can we tell what device someone is actually > using? Systems > nowadays usually have more than one sound device. On-board analogue, > on-board digital, > in/out/duplex, HDMI for feeding screens with speakers, etc. > If I use my (on-board) /dev/dsp4.1 as the main playback device on > FreeBSD, it doesn't > mean that this is the same for every FreeBSD user. Someone else might > use /dev/dsp7.0 > instead because they want to use the the builtin speakers of their > screen, hooked up via > HDMI. > On top of that, the situation is different for each OS. > On FreeBSD, we have for example /dev/dspX.Y, whereas Solaris has only > /dev/dsp and > /dev/dspX (with X and Y equal or greater than 0). Solaris also has an > /dev/audio, which is > completely missing on FreeBSD 10, but existed in earlier releases. > Both FreeBSD and Solaris have a /dev/sndstat, but the devices are > behaving differently. > No idea about these things on the Linux side, but I bet they are > looking different from > both FreeBSD and Solaris. > >> If it can't be fixed I will have to add a wiki page. > I think some general instructions on the Wiki would be much more useful, yes. > > > > Kind regards, > > Martin Etteldorf > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > _______________________________________________ > cdesktopenv-devel mailing list > cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel |
|
From: Martin E. <ett...@gm...> - 2016-06-13 10:39:49
|
Hello Antonis,
On Mon, Jun 13, 2016 at 12:10 PM, Antonis Tsolomitis
<ant...@gm...> wrote:
> For example, I see patches sent through the list
> that are specific to OpenBSD, or to Solaris etc.
> So CDE does not get patched with a "common denominator" attitude.
> It does things differently on different platforms. I find this to be
> normal.
Yes, but different platforms are one thing. Making a patch for every possible
scenario on every platform is next to impossible, though. As mentioned. I
have seven audio devices, someone else may have 4, or 14.
Some people are probably okay with chown /dev/dsp*, others might want to
chown their primary sound device only, or a dedicated secondary one. There
are way too many variables to come up with a single patch.
> What is /dev/$ITE found in Xstartup. It does not exist in any of my systems.
The dtlogin manpage reads:
=======================================================
In order to support "Command Line Login" mode, the display
must have an associated Internal Terminal Emulator (ITE)
device. By default, dtlogin associates the ITE device "con-
sole" ( /dev/console) with display ":0".
=======================================================
Kind regards,
Martin Etteldorf
|
|
From: Antonis T. <ant...@gm...> - 2016-06-13 16:48:58
|
I added a wiki page and linked to that with a note from the "Linux Build" page. Antonis. On 13/06/2016 01:39 μμ, Martin Etteldorf wrote: > Hello Antonis, > > > > On Mon, Jun 13, 2016 at 12:10 PM, Antonis Tsolomitis > <ant...@gm...> wrote: >> For example, I see patches sent through the list >> that are specific to OpenBSD, or to Solaris etc. >> So CDE does not get patched with a "common denominator" attitude. >> It does things differently on different platforms. I find this to be >> normal. > Yes, but different platforms are one thing. Making a patch for every possible > scenario on every platform is next to impossible, though. As mentioned. I > have seven audio devices, someone else may have 4, or 14. > Some people are probably okay with chown /dev/dsp*, others might want to > chown their primary sound device only, or a dedicated secondary one. There > are way too many variables to come up with a single patch. > >> What is /dev/$ITE found in Xstartup. It does not exist in any of my systems. > The dtlogin manpage reads: > ======================================================= > In order to support "Command Line Login" mode, the display > must have an associated Internal Terminal Emulator (ITE) > device. By default, dtlogin associates the ITE device "con- > sole" ( /dev/console) with display ":0". > ======================================================= > > > Kind regards, > > Martin Etteldorf |
|
From: <ib...@gm...> - 2014-02-17 20:59:58
|
On Mon, Feb 17, 2014 at 12:05:12AM +0200, Antonis Tsolomitis wrote: > > If CDE starts through dtlogin immediately after reboot the sound does > not work. > This is because dtlogin has no instructions to start the pulse system. > > But what is the proper way to start the pulse system for the user? > > If we login to CDE with lightdm then stop lightdm, start dtlogin and > login CDE the sound works. > > So what is the correct way to fix this? > > Antonis. Definitely not by always starting pulse. I use OSS4 because the ALSA drivers do not work here, so have some strong feelings in that regard. Questions: -When does lightdm start pulse? On start, or on login? (If you stop lightdm from VT1 without logging in, is pulse started?) -Is pulse running as a system daemon or as a user daemon? (look at ps -ef, field 1) -If pusle is a system daemon, is pulse configured to autostart when lightdm starts? (This is my guess for what happens, just because of the nature of upstart...look in /etc/init/) HTH, Isaac Dunham |
|
From: Antonis T. <ant...@gm...> - 2014-02-20 06:07:48
|
>
> Questions:
> -When does lightdm start pulse? On start, or on login?
> (If you stop lightdm from VT1 without logging in, is pulse started?)
Lightdm starts pulse for its own use (at least) and indeed when lightdm
runs, pulse runs with
lightdm authority. So one could assume that this is irrelevant. When you
login
to CDE with lightdm you can see pulse running with lightdm authority for
a few seconds and
then the process disappears, and no process with name containing "pulse"
exists.
BUT if I start a sound application (say vlc) I see that pulseaudio gets
started with user authority.
In pstree it appears as
|-pulseaudio-+-gconf-helper
| `-2*[{pulseaudio}]
as a child of init.
So what gets wrong when CDE is started by dtlogin? When dtlogin starts
CDE (from boot: get to lightdm screen, switch to console,
stop lightdm, start dtlogin, and login to CDE)
vlc looks working (you can see it plays the sound) but no sound is
produced and no pulse process exists.
Does it work to anybody? Is it my PC problem maybe? Or something blocks
pulse from starting?
Antonis.
|
|
From: <ib...@gm...> - 2014-02-21 07:48:15
|
On Thu, Feb 20, 2014 at 08:07:38AM +0200, Antonis Tsolomitis wrote:
>
> >
> > Questions:
> > -When does lightdm start pulse? On start, or on login?
> > (If you stop lightdm from VT1 without logging in, is pulse started?)
>
> Lightdm starts pulse for its own use (at least) and indeed when lightdm
> runs, pulse runs with
> lightdm authority. So one could assume that this is irrelevant. When you
> login
> to CDE with lightdm you can see pulse running with lightdm authority for
> a few seconds and
> then the process disappears, and no process with name containing "pulse"
> exists.
>
> BUT if I start a sound application (say vlc) I see that pulseaudio gets
> started with user authority.
>
> In pstree it appears as
>
> |-pulseaudio-+-gconf-helper
> | `-2*[{pulseaudio}]
>
> as a child of init.
>
>
> So what gets wrong when CDE is started by dtlogin? When dtlogin starts
> CDE (from boot: get to lightdm screen, switch to console,
> stop lightdm, start dtlogin, and login to CDE)
> vlc looks working (you can see it plays the sound) but no sound is
> produced and no pulse process exists.
>
> Does it work to anybody? Is it my PC problem maybe? Or something blocks
> pulse from starting?
>
> Antonis.
>
Looks like you missed my third question/comment:
>> -If pulse is a system daemon, is pulse configured to autostart
>> when lightdm starts?
>> (This is my guess for what happens, just because of the nature of
>> upstart...look in /etc/init/)
And so far, it sounds like that is the most likely prospect.
>From what I see,
-/etc/init/lightdm.conf has these lines:
emits login-session-start
emits desktop-session-start
emits desktop-shutdown
-/etc/init/pulseaudio.conf has this line
start on started dbus
So lightdm has something to do with dbus starting, and dbus triggers pulse,
and...I'm not sure what the rest of the story is (besides "you might want
dtlogin.conf")
HTH,
Isaac Dunham
|
|
From: Antonis T. <ant...@gm...> - 2014-02-21 08:50:37
|
Στις 21/02/2014 09:48 πμ, ο/η ib...@gm... έγραψε:
> On Thu, Feb 20, 2014 at 08:07:38AM +0200, Antonis Tsolomitis wrote:
>>> Questions:
>>> -When does lightdm start pulse? On start, or on login?
>>> (If you stop lightdm from VT1 without logging in, is pulse started?)
>> Lightdm starts pulse for its own use (at least) and indeed when lightdm
>> runs, pulse runs with
>> lightdm authority. So one could assume that this is irrelevant. When you
>> login
>> to CDE with lightdm you can see pulse running with lightdm authority for
>> a few seconds and
>> then the process disappears, and no process with name containing "pulse"
>> exists.
>>
>> BUT if I start a sound application (say vlc) I see that pulseaudio gets
>> started with user authority.
>>
>> In pstree it appears as
>>
>> |-pulseaudio-+-gconf-helper
>> | `-2*[{pulseaudio}]
>>
>> as a child of init.
>>
>>
>> So what gets wrong when CDE is started by dtlogin? When dtlogin starts
>> CDE (from boot: get to lightdm screen, switch to console,
>> stop lightdm, start dtlogin, and login to CDE)
>> vlc looks working (you can see it plays the sound) but no sound is
>> produced and no pulse process exists.
>>
>> Does it work to anybody? Is it my PC problem maybe? Or something blocks
>> pulse from starting?
>>
>> Antonis.
>>
> Looks like you missed my third question/comment:
Indeed. I am sorry. Actually, I did not understand it's importance.
>>> -If pulse is a system daemon, is pulse configured to autostart
>>> when lightdm starts?
>>> (This is my guess for what happens, just because of the nature of
>>> upstart...look in /etc/init/)
> And so far, it sounds like that is the most likely prospect.
> From what I see,
> -/etc/init/lightdm.conf has these lines:
>
> emits login-session-start
> emits desktop-session-start
> emits desktop-shutdown
>
> -/etc/init/pulseaudio.conf has this line
> start on started dbus
>
> So lightdm has something to do with dbus starting, and dbus triggers pulse,
> and...I'm not sure what the rest of the story is (besides "you might want
> dtlogin.conf")
>
> HTH,
> Isaac Dunham
>
OK. You are right. But do you see what should be done and how?
Antonis.
|
|
From: <ib...@gm...> - 2014-02-22 15:28:03
|
On Fri, Feb 21, 2014 at 10:50:25AM +0200, Antonis Tsolomitis wrote: > ???????? 21/02/2014 09:48 ????, ??/?? ib...@gm... ????????????: > > On Thu, Feb 20, 2014 at 08:07:38AM +0200, Antonis Tsolomitis wrote: > >>> -If pulse is a system daemon, is pulse configured to autostart > >>> when lightdm starts? > >>> (This is my guess for what happens, just because of the nature of > >>> upstart...look in /etc/init/) > > And so far, it sounds like that is the most likely prospect. > > From what I see, > > -/etc/init/lightdm.conf has these lines: > > > > emits login-session-start > > emits desktop-session-start > > emits desktop-shutdown > > > > -/etc/init/pulseaudio.conf has this line > > start on started dbus > > > > So lightdm has something to do with dbus starting, and dbus triggers pulse, > > and...I'm not sure what the rest of the story is (besides "you might want > > dtlogin.conf") > > > > HTH, > > Isaac Dunham > > > > OK. You are right. But do you see what should be done and how? > > Antonis. > Write an upstart job for dtlogin. Upstart jobs are *.conf files in /etc/init/, and you may wish to start with lightdm.conf. But I'm afraid that's all I can tell you, since I use sysvinit. HTH, Isaac Dunham |
|
From: Antonis T. <ant...@gm...> - 2014-02-23 19:41:20
|
Στις 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. > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > cdesktopenv-devel mailing list > cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel 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. If it doesn't then dtlogin may face more problems in the future when it will be used by someone to login to, say, Mate which will require pulse. Thanks again, I will add my username to audio and test your suggestion. Antonis. |
|
From: Johannes v. R. <jr...@vr...> - 2014-02-23 21:10:18
|
On 02/23/2014 08:41 PM, Antonis Tsolomitis wrote: > 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. The question probably is, how tightly we want to integrate PulseAudio into 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. I would like to see the Linux community finally opting for one audio soultion, and it seems to me, PulseAudio might be it. But i'd like to keep in mind that there are plenty of alternatives, and Linux isn't the only kid on the block. > If it doesn't then dtlogin may face more problems in the future > when it will be used by someone to login to, say, Mate which will > require pulse. Apparantly, the way PulseAudio is started differs from distro to distro. But generally speaking, I fail to see how this has to be a job of the login manager. When I started gnome-session (Gnome 2) from a pty in rulevel 3 (before I added my user to the "audio" group), PulseAudio was working without problems. But as I said earlier, I don't have much of an insight into the workings of PulseAudio (It seems it's just a daemon, but there's so much more going on...) Cheers, J. -- Johannes von Rotz Bachmannweg 11 8046 Zuerich +41 79 705 23 96 |
|
From: Jon T. <jo...@ra...> - 2014-02-23 23:12:11
|
On Sun, 23 Feb 2014, Johannes von Rotz wrote: > On 02/23/2014 08:41 PM, Antonis Tsolomitis wrote: >> 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. > > The question probably is, how tightly we want to integrate PulseAudio > into CDE. > Probably not at all.. CDE does not make use of any audio capabilities other than the standard X bell. It might be nice to start the required services in Xsession on each system, but as you mentioned, everybody seems to do it differently. [...] -- Jon Trulson "It is a truism that almost any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so." —Robert A. Heinlein, science-fiction author (1907-1988) |
|
From: Pascal S. <Pas...@cu...> - 2014-02-23 23:23:53
|
On Sun, 23 Feb 2014 16:12:04 -0700 (MST), Jon Trulson wrote: > On Sun, 23 Feb 2014, Johannes von Rotz wrote: > > > On 02/23/2014 08:41 PM, Antonis Tsolomitis wrote: > >> 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. > > > > The question probably is, how tightly we want to integrate PulseAudio > > into CDE. > > > > Probably not at all.. CDE does not make use of any audio capabilities > other than the standard X bell. > > It might be nice to start the required services in Xsession on each > system, but as you mentioned, everybody seems to do it differently. Agreed. Every distribution does it differently, so modifying Xsession should be left to the individual packagers. > [...] > > -- > Jon Trulson > > "It is a truism that almost any sect, cult, or religion will > legislate its creed into law if it acquires the political power to do > so." —Robert A. Heinlein, science-fiction author (1907-1988) > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > cdesktopenv-devel mailing list > cde...@li... > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > |
|
From: Isaac D. <ib...@gm...> - 2014-02-24 05:10:02
|
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 |
|
From: Robert T. <ro...@to...> - 2014-02-24 17:28:16
|
> On Sun, Feb 23, 2014 at 09:41:11PM +0200, Antonis Tsolomitis wrote: > > > > > > 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. Not everyone uses distros that ship Pulse by default. In fact, not everyone uses Linux. This is especially true for CDE, as it has what one might call a rather "traditional" UNIX install base by virtue of its history. Plus, the sorts of people that are likely to run a decidedly "retro" desktop nowadays are not necessarily the sorts that are fans of pulseaudio... :) In other words, pulse is standard on some of the platforms that CDE runs on, uncommon on others, and virtually unheard of on others still. So I'd like to voice my support for Isaac's idea; integration between CDE and pulse is not something that should be done directly. -Rob |
|
From: Johannes v. R. <jr...@vr...> - 2014-02-23 17:28:14
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X