Bug 851349

Obsolete? What provides network functionality? PulseAudio? I haven't seen any unit file for that. Even manually running the PA server is heavy deal because it terminates after last client disconnects. Even PA author states it's not ready for server use. So this is pure feature removal.

1) I'm trying to think of a valid case for running any SDL app with network forwarded sound - not coming up with any ideas off the top of my head.

2) Outputting sound via esound or arts only helps if the environment you're running under uses esound/arts as its sound base. The number of desktops we ship now that do that is effectively zero, if not actually zero.

(In reply to comment #2)
> 1) I'm trying to think of a valid case for running any SDL app with network
> forwarded sound - not coming up with any ideas off the top of my head.
> 
Try this sentence:

I'm trying to think of a case for running any app with network forwarded sound.

Cannot find any? You have poor imagination. Never running application on remote machine with consuming the output on local one? Think about terminal servers, about home theater systems, about comfort when listing your music by earphones connected to your mobile machine while running the system on a powerful host. Or just the pure need because not all machines have audio output?

> 2) Outputting sound via esound or arts only helps if the environment you're
> running under uses esound/arts as its sound base. The number of desktops we
> ship now that do that is effectively zero, if not actually zero.

Freedom of choice? Providing building blocks for user to get abilities to do it if `number of desktops we ship is zero'? Why do you think people have to use desktop environment? Especially if does not satisfy their needs (cause `we do not ship them'.

E.g. getting the esound over network is just about exporting ESPEAKER environment variable and setting the esound output in the application. (NAS output which I'm thinking about enabling on SDL now does not require even it. It integrates with X11 automatically.)

(In reply to comment #3)
> (In reply to comment #2)
> > 1) I'm trying to think of a valid case for running any SDL app with network
> > forwarded sound - not coming up with any ideas off the top of my head.
> > 
> Try this sentence:
> 
> I'm trying to think of a case for running any app with network forwarded
> sound.
> 
> Cannot find any? You have poor imagination. Never running application on
> remote machine with consuming the output on local one? Think about terminal
> servers, about home theater systems, about comfort when listing your music
> by earphones connected to your mobile machine while running the system on a
> powerful host. Or just the pure need because not all machines have audio
> output?

I stated SDL because I meant SDL, and that's what this bug was about. Looking through the SDL apps we ship, they certainly don't appear to include apps that make sense to run remotely in most all normal context. It's possible I missed a couple, but they do appear to be pretty much all games that would be run locally.

> > 2) Outputting sound via esound or arts only helps if the environment you're
> > running under uses esound/arts as its sound base. The number of desktops we
> > ship now that do that is effectively zero, if not actually zero.
> 
> Freedom of choice? Providing building blocks for user to get abilities to do
> it if `number of desktops we ship is zero'? Why do you think people have to
> use desktop environment? Especially if does not satisfy their needs (cause
> `we do not ship them'.

If the user desperately wants to build infrastructure based on a sound server we haven't shipped the binary for in 5 years and is effectively unmaintained I suppose they can. That doesn't necessarily mean it's a good idea or something we should encourage them doing instead of just fixing PA, for example.

*** Bug 980763 has been marked as a duplicate of this bug. ***

Esound is still there. I will reintroduce Esound support into SDL.

That is not very helpful. We are struggling to cut a ton of gratitious dependencies on minor libraries/audio frameworks/you name it, very time we try to release a non-oversize live image.

But, as long as we don't have any sdl apps on the live image, I don't care that much.

SDL outputs are implemented as plug-ins. There are no mandatory huge run-time dependencies because they are enabled at build-time.

to Petr Pisar from 980763

why Esound had been removed from Fedora ?

Esound present in Fedora ?!

esound-devel, esound-libs, esound-tools... 

they are available in the repositories ?!

They are but they shouldn't. Matthias Clasen should know the real motivation because he requested the change.

but then why do not normally work with SDL pulseaudio and alsa?
at pulseaudio callback occurs earlier than the time. at alsa processor takes too much CPU time. normally works only with ESD and then plays the sound delay...

Its ok, I just didn't want to maintain it anymore in the desktop team, which is why we've orphaned it. And I don't want it to be pulled onto the desktop live image. But I don't mind if it lives on in some corner of the Fedora universe...

SDL-1.2.15-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/SDL-1.2.15-10.fc19

SDL-1.2.15-11.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.