[LAU] perhaps why some of us have more trouble w/ pulseaudio than others (ICE1712/M-audio delta problem w/ pulseaudio)

Hartmut Noack zettberlin at linuxuse.de
Mon May 10 10:40:51 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 10.05.2010 11:32, schrieb rosea.grammostola:
> On Mon, 2010-05-10 at 09:52 +0200, Hartmut Noack wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am 10.05.2010 03:00, schrieb Fernando Lopez-Lezcano:
>>> On Sat, 2010-05-08 at 18:23 -0400, Paul Davis wrote:
>>>>
>>>>
>>>>
>>>>         Now that would be shocking I'd say. Since Suse 8.0 the ICE1712
>>>>         was
>>>>         always the most reliable chipset one could possibly find for
>>>>         Linux. So
>>>>         that would be a major regression and should be a show-stopper
>>>>         for alsa.
>>>>         
>>>>         BUT: the link points to a bug that affects puls audio and it
>>>>         affects it
>>>>         with a EWS88MT wich is one of the not-so typical ICE1712-cards
>>>>         like the
>>>>         EWX or the MAudio Audiophile and Delta-Series.
>>>>         
>>>>         So how about these cards and alsa/jack? Any trouble out there
>>>>         with
>>>>         bleeding-edge distros?
>>>>         
>>>>
>>>> my reading of this (and the related ALSA bug report) is that this is a
>>>> Pulse-only bug, because its related to Pulse's attempt to provide a
>>>> mapping of whatever-it-is-that-the-hw-provides into
>>>> standard-things-that-users-can-know-and-love.
>>>>
>>>> JACK will just use the channels as single, undifferentiated channels
>>>> and doesn't care about their names, function,etc. etc.
>>>>
>>>> i could be wrong in my assessment.
>>>
>>> I think you are correct. Pulse points to alsa as the culprit, alsa
>>> ignores the issue, it may _not_ be an issue for alsa, I don't know.
>>
>>
>> I agree with Paul. This is a problem with PA, alsa works as expected and
>> perfectly OK with the envy24-chipset.
>> Even if one likes to call it a "bug" that alsa presents all envy24-cards
>> more or less the same though they are physically quiet different, I
>> would call this a minor flaw since technically there is nothing broken here.
>>
>> Reading the thread on the PA-site I feel a bit uneasy. Lennart demands
>> alsa to report a "front"-device wich is nonsense since AFAIK only the
>> terratec 5.1 uses the envy24-chipset to produce a set of outputs for
>> surround-speakers. All others are cards for musicians delivering 2+2,
>> 4+2 ore more analogue/digital i/o ports that are all considered the
>> same, delivering a pristine hifi-signal that the user is invited to send
>> whatever source he/she likes to send to.
>>
>> What will PA do with a Delta 10x10? Trying to send "front" to the first
>> 2, "rear" to the next 2, a lowpassed "sub" to the fith and then what?
>>
>> Why cant PA just offer a stereo-out for the first 2 ports of the envy
>> and secondary stereo-outs for the rest plus a digital-out for the
>> spdif-ports on these cards? Do they consider users, that spend quite
>> some money on such a card, too stupid to find out, why the secondary
>> stereo-outs do not deliver a signal with a MAudio audiophile?
>> And NO! I would NOT consider it a progress, if alsa would start to tell
>> me, that the first two ports of my MAudio would be "front-speaker-outs"
>> for they are not.
>>
>> This musing about "broken" alsa-drivers that need to be "fixed" in the
>> thread at PA increases the bad feeling about PA's relation and awarenes
>> to pro-audio.
> 
> Or Lennart is just right and the driver in ALSA is not what it should be
> for this card. 
> 
> \r

If the alsa-driver for my MAudio audiophile would tell me, that the
first 2 output-ports would be "front-speaker"-outputs the the
alsa-driver would be broken. Because this card is not meant for
front-rear-speaker setups but for pro-audio-use.

Of course it would be nice, if alsa would indicate the difference
between ports, that have physical DAC-outputs and those, wich have not.

What I am trying to say is: the PA-people should be aware, that there is
pro-audio-hardware out there, that can be used for desktop-audio too but
is still quite different by design compared with the average HDA-chip.
So if Lennart wants to make users of these cards happy with PA, then he
should make PA work for this card in the same way, envy24 is working.
Adeaquately adapted to the cards design that is.

To avoid misunderstanding: I think, that PA is a great idea. It adresses
every problem, audio exposed the Linux-users to for years now. So I
advocate PA for the desktop and will continue to do so. For nobody would
like to see yet another attempt to finally make things right in that
domain. PA also behaves quite well with jack even though it should
connect to it instead of simply fall asleep as jack starts.

Still: a working driver should not be changed in favour to PAs schemes,
PA should adapt to any working driver. And the ICE1712-driver is a
working driver. It gives me access to every aspect of the cards features
and it runs stable with jack at less than 5 ms Latency so please! Do NOT
touch it!

best regs

HZN


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkvn4rMACgkQ1Aecwva1SWN63gCfa+/YGnRdSfUv4TEq1Ez6RVPX
6fQAnjtWGBraEFDu/pDzH0Xwt9KR0ZaU
=Pj2v
-----END PGP SIGNATURE-----


More information about the Linux-audio-user mailing list