On Tue, Oct 20, 2009 at 11:00 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Please fix you're broken lineends.
>
> 'Twas brillig, and Markus Rechberger at 20/10/09 21:03 did gyre and gimble:
>>
>> I'm also using pulseaudio for one of my product actually (just because
>> the devices we ship have
>> to work without altering the installed system).
>
> As I've explained on numerous occasions, that's a flawed argument. You were
> hell bent on insisting that even if there is a clear bug in an installed
> system, *you* have to work around that bug rather than getting the distro in
> question to fix the bug at root and issue an update.
>
> While it's a laudable aim to make things work out of the box, it's totally
> unrealistic to work around things in the way you suggested.
>
> I spent numerous hours supporting you and yet all you did was complain,
> never gave any example code that exhibited crashes or segfaults, did not
> provide any backtraces or other debug information, despite repeated
> requests.
well reopening the audio device was the issue. Debug information are not usable
as the crashes appeared to happen randomly once the PA emulation layer was
involved, some general issues maybe valgrind might show up more (well
valgrind always complains with our applications and we do not use more than
easy alsa or PA).
Alsa:
----
dev->fmt.format = SND_PCM_FORMAT_S16_LE;
dev->fmt.channels = 2;
dev->fmt.rate = 48000;
if (dev == NULL)
return NULL;
if ((result = snd_pcm_open( (snd_pcm_t**)&dev->playback,
"default", SND_PCM_STREAM_PLAYBACK, /*SND_PCM_NONBLOCK*/0))<0)
{
free(dev);
mc_printf("alsa-audio: unable to connect audio service\n");
return NULL;
}
reset()
snd_pcm_reset((snd_pcm_t*)adev->playback);
snd_pcm_prepare((snd_pcm_t*)adev->playback);
(I suspect the implementation of those functions have a problem too, not sure
if it's server or client based only).
close()
if ((snd_pcm_t*)dev->playback) {
snd_pcm_drain((snd_pcm_t*)dev->playback);
snd_pcm_close((snd_pcm_t*)dev->playback);
}
free(dev);
snd_config_update_free_global();
play():
ret = snd_pcm_writei((snd_pcm_t*)adev->playback, buf, towrite);
PA:
open()
paspec.channels = 2;
paspec.rate = 48000;
paspec.format = PA_SAMPLE_S16LE;
attr.maxlength = 10000;
attr.tlength = 5000;
attr.prebuf = 4000;
attr.minreq = 3000;
ps = pa_simple_new(NULL, "Sundtek", PA_STREAM_PLAYBACK, NULL,
"Media Framework", &paspec, NULL, &attr, &error);
pa_simple_flush(ps, &error);
flush():
pa_simple_flush(adev->ps, &error);
play():
nwritten = pa_simple_write(adev->ps, buf, length, &error);
close():
pa_simple_free(ps);
I'm not doing anything special. But since that piece of software is
used with different
systems the symptoms can vary of course. I mainly noticed Ubuntu 9.04 and
Ubuntu 8.10, both systems worked stable with alsa but became unstable
with pulseaudio.
> Due to this, all we have is "your word" that this is going on, but
> no way to verify, and more importantly fix, any problems that really do
> exist. Until you provide this information, all of your claims are completely
> baseless.
>
note you wouldn't have to give any support if at least the alsa layer
would just work
as it should. Well once it works there's not much to do for us anymore. if you
advice to add some debug callback to our audio code we can do so and collect the
dumps from our customers. (please note the code is restricted but as
long as it comes
to audio we can provide the necessary information).
>
> You've also fallen into the classic trap because you used a single distro
> with a known poor implementation of a pulse-based audio stack and yet you
> projected all your problems on to pulseaudio itself. You've only reinforced
> that with what you wrote in this mail.
>
it's not just me, customers were complaining the problems to us and
when buying a product
they cannot care less if their distribution supports it properly or
not the product has to work.
> In addition the classic, "I don't use the network therefore pulseaudio is
> useless" argument is also completely baseless. This is such a tiny part of
> what PA is all about and to use it as an argument just highlights the lack
> of understanding.
it's a nice to have, aside of that I don't see much more value of it
(this is my personal opinion about it
of course everyone can have his own opinion).
The main point is that the default audio playback has to work stable,
afterwards those extra nice to have
features are ok.
People usually don't point out about the good things, it's the same
with our work. Things have to work
straight otherwise they'll complain (the /. article is just another
confirmation for that).
Poeple will stop complaining about it as soon as it reaches full Alsa
compatibility and the same stability
which in general leads to less support work.
Markus
