Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Iain Sandoe]

I forgot to say...

this should (now I fixed a typo in the machine name) also solve the LE
byte-swapping problem on Pismo (by soft-swapping).

It is still not obvious why the Pismo does not swap in H/ware (it has the
smae AWACS chip id as the Lombard).

if you downloaded the modules or the diff before 00:00 GMT 19/01/2001 you
need to fetch it again.

cioa,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Takashi Oe]

On 1/18/01 6:04 PM, Iain Sandoe wrote:

>
> I forgot to say...
>
> this should (now I fixed a typo in the machine name) also solve the LE
> byte-swapping problem on Pismo (by soft-swapping).

Can't apps cope with it if it doesn't do the byte-swapping in H/W?  If it
can, I think the code should be removed.  No software translation in kernel
if we can avoid it at all.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Iain Sandoe]

>> this should (now I fixed a typo in the machine name) also solve the LE
>> byte-swapping problem on Pismo (by soft-swapping).
>
> Can't apps cope with it if it doesn't do the byte-swapping in H/W?  If it
> can, I think the code should be removed.  No software translation in kernel
> if we can avoid it at all.

I agree 100% - the kernel should _never_ have been doing this stuff in the
first place (it can't even make a particularly good job of some of it
without fp).... and, AFAIK, that is the way of things for ALSA.

However, in OSS-land, it seems that quite a few apps rely on it (or don't
treat endian-ness sensibly) - OK, so they are, in some sense, buggy ...

... by comparison with the large amount of other code already in there to do
rate expansion and compression/decompression it is a relatively small price
to pay for having all pmac machines behave the same...

... at the next revision of the driver we could try issuing it with "16bit
44k1 Signed BE" only - and see how much of the desktop world works ;-)

iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Takashi Oe]

On 1/18/01 7:47 PM, Iain Sandoe wrote:

[...]
> ... by comparison with the large amount of other code already in there to do
> rate expansion and compression/decompression it is a relatively small price
> to pay for having all pmac machines behave the same...

I know it's a small price, and some of those translations shouldn't be there
either, I think.

> ... at the next revision of the driver we could try issuing it with "16bit
> 44k1 Signed BE" only - and see how much of the desktop world works ;-)

Let's fix apps and keep the kernel lean.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Iain Sandoe]

Fri, Jan 19, 2001, Takashi Oe wrote:
> On 1/18/01 7:47 PM, Iain Sandoe wrote:
> [...]
>> ... by comparison with the large amount of other code already in there to do
>> rate expansion and compression/decompression it is a relatively small price
>> to pay for having all pmac machines behave the same...
>
> I know it's a small price, and some of those translations shouldn't be there
> either, I think.

I think we agree well on the principles.

>> ... at the next revision of the driver we could try issuing it with "16bit
>> 44k1 Signed BE" only - and see how much of the desktop world works ;-)
>
> Let's fix apps and keep the kernel lean.

---

my only justification is a case of expediency:

many apps ; one driver ; very, very few linux ppc audio developers.

---

OSS is legacy - and not well suited to expressing the PPC hardware.

I think that we should invest the littlest time in fixing legacy
  - accept that the CPU cycles have to be executed somewhere (although we
agree that should be in User mode).

So we can then apply these few developers to the future :
 - where apps will have to be expecting the translations to be carried out
in user space.
 - to solving the real problems (like making the latency sufficiently small
for professional audio work).

If and when ALSA is accepted into linux we can/will throw this current
driver away.  If it is built as a module - it has no lasting impact on the
kernel.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Takashi Oe]

On 1/18/01 8:30 PM, Iain Sandoe wrote:

> my only justification is a case of expediency:
>
> many apps ; one driver ; very, very few linux ppc audio developers.

Do you have any hard number?  How many *popular* apps does the pismo change
break?  I don't there are so many linux audio apps to begin with.

> If and when ALSA is accepted into linux we can/will throw this current
> driver away.  If it is built as a module - it has no lasting impact on the
> kernel.

I think ALSA will be in, but do you know for sure OSS will go away?
Besides, people will be using 2.4 for a long time, and I don't think OSS
will go away from 2.4 ever.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Iain Sandoe]

Fri, Jan 19, 2001, Takashi Oe wrote:
> On 1/18/01 8:30 PM, Iain Sandoe wrote:

>> my only justification is a case of expediency:

I should have said temporary** expediency.

>> many apps ; one driver ; very, very few linux ppc audio developers.
>
> Do you have any hard number?  How many *popular* apps does the pismo change
> break?

well, I don't have a hard number - I guess a count off the stuff linked to
http://www.linuxdj.com/audio/lad/ might be quite accurate

- but if you do a quick check back over this list you will find that quite a
few 'popular' (including major ones like xmms + its plug-ins, arts, ecasound
etc.) one have  been mentioned. (even sox produces LE raw output by default
- yuck!).

Yes, the broken ones could/should all be fixed* (some have BTW) - any
volunteers?   (I could *very* easily make the driver support hardware-only
formats).

>I don't there are so many linux audio apps to begin with.

sadly, true - but there are more apps that _use_ audio - like kde - which
_is_ (I am told) broken for pismo (I don't have one) without LE data support
and, of course, games.

>> If and when ALSA is accepted into linux we can/will throw this current
>> driver away.  If it is built as a module - it has no lasting impact on the
>> kernel.
>
> I think ALSA will be in, but do you know for sure OSS will go away?
> Besides, people will be using 2.4 for a long time, and I don't think OSS
> will go away from 2.4 ever.

ALSA has a backward compatibility OSS layer - implemented according to the
kinds of rules that we both agree are desirable.

I expect ALSA will get "back-ported" to 2.4.0 - since (although it is not
currently, officially in linux) it is being developed on 2.4

- no OSS won't go away from 2.4 - I am sure - but development is likely to
stop - and people are likely to use an ALSA compatibility layer rather than
load/reload drivers.

====

Actually, I'm not sure why I'm debating ;-/

- I agree with you - and I have little use for the compressed formats
personally.

I am interested in professional quality audio on the right platform (i.e.
PPC)... I was working on the dmasound driver in order to understand the
hardware well enough to do an ALSA version (which of course has no such
translations internally) ;-)))

I guess sometimes it's nice to "keep end users happy" tho' :-)

iain.

---
* basically, to fix an OSS app that does not do its own conversion can be
quite a lengthy job... plumbing in the necessary provisions. endian-swapping
is a small task - rate conversion/decompression might not be.

of course, you avoid kernel bloat at the expense of application bloat -
which is solved by the following:

**It is my understanding that ALSA provides a mid-layer based on a
user-space lib.  This means that it is not necessary for each app to provide
the translations - whilst they are still executed in the correct state -
i.e. user.  No kernel bloat, no application bloat.
------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Takashi Oe]

On 1/18/01 10:11 PM, Iain Sandoe wrote:

> - but if you do a quick check back over this list you will find that quite a
> few 'popular' (including major ones like xmms + its plug-ins, arts, ecasound
> etc.) one have  been mentioned. (even sox produces LE raw output by default
> - yuck!).

Hmm, odd.  I've used all mentioned here except "arts" which I have never
used on a nubus mac here.  The nubus version of awacs doesn't have h/w byte
swapping.  So, I believe those apps worked at one point or fixes exist
already.

>
> Yes, the broken ones could/should all be fixed* (some have BTW) - any
> volunteers?   (I could *very* easily make the driver support hardware-only
> formats).
>
>> I don't there are so many linux audio apps to begin with.
>
> sadly, true - but there are more apps that _use_ audio - like kde - which
> _is_ (I am told) broken for pismo (I don't have one) without LE data support
> and, of course, games.

You know, some apps are so broken that they do the byte swapping themselves
so as to feed LE data, in which case the CPU will be doing double byte
swapping on PISMO and possibly others.  No thanks.

> I guess sometimes it's nice to "keep end users happy" tho' :-)

True, but we had no audio app working (without a patch or two) some years
ago, and I believe we are making progress.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] 2.4.1p4 : dmasound ed21- Pismo byte-swap

[Iain Sandoe]

I believe there is a danger we are missing the point of ed21 of the driver.

1/ the main point... is that I believe the dbdma stuff is now working
reliably - which should make record functional and playback robust.

2/ In fact - the driver has, for some time, been compliant (AFAICT) with OSS
Progammer's Guide 1.1 (June 2000).  So, I suppose that I could just say "if
the app gives noise - it's broken".

If anyone believes that there is an error in this compliance - I'll be happy
to try & fix it or help someone else do so.

3/ The "pismo LE fix" is a small part and quite easily backed out of/left in
as people like.  It is no more/less "correct" to include it in the driver
than some of the other stuff that's already there.

4/ The driver offers (in the official, released version) a number of
non-native formats as valid input.  I do not believe it is "strictly
necessary" under OSS rules to do this.

-----

otherwise, I agree with you on the principles (not putting stuff in the
kernel that belongs in user space).

I would find it just as wasteful as you to swap data twice - for 'real'
(a.k.a. paid) work I write a fair bit of real time dsp code...

... but I don't think I had better comment further on stuff which is mostly
reported to me rather than tested (personally) by me.  It is, of course,
possible that people are reporting errors with old versions of apps - but
this path is usually checked in discussion of reported "format bugs" in the
driver.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/