Re: patch for am7930 audio
At Thu, 10 Sep 2020 10:27:23 -0400 (EDT), Mouse wrote: > > am7930intr.s [...] already has been disabled 11 years ago due to > > adapt to MI softint(9) [*]. > > Oh! Okay, then, yes, if it's not even being used there's no point > keeping it. Anyone who needs it can get it back from revision history. Thank you. I will commit. --- Tetsuya Isaki
re: patch for am7930 audio
> By the way, I'm not so familiar to sparc. > audioamd(4) has many assembly code (though they look very old stuff). > Is there any (historical or traditional) reason why I should not > remove these? i would just ignore it. it's currently unused and if someone wants to fix it up, it's sitting there easy to look at, but it is not currently used and is known needing work for years ago API changes, so don't feel you can't change the code around it. it's just more work for someone who may eventually revive it. .mrg.
Re: patch for am7930 audio
mo...@rodents-montreal.org (Mouse) writes: >Some SPARCs have audio hardware not capable of more than 8kHz. Some >have hardware that can handle CD-quality audio (and possibly better). >I don't know where the 7930 falls on that spectrum. The am7930 is an ISDN chip and limited to 8kHz uLaw or aLaw audio, it can do some filtering and generate dial tones, but not CD-quality. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: patch for am7930 audio
> am7930intr.s [...] already has been disabled 11 years ago due to > adapt to MI softint(9) [*]. Oh! Okay, then, yes, if it's not even being used there's no point keeping it. Anyone who needs it can get it back from revision history. >> [...] significant impact on performance at higher sample rates. > I think that am7930 works only at 8000Hz. > Does sparc's one support sample rate other than 8000Hz? Some SPARCs have audio hardware not capable of more than 8kHz. Some have hardware that can handle CD-quality audio (and possibly better). I don't know where the 7930 falls on that spectrum. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: patch for am7930 audio
At Wed, 9 Sep 2020 10:53:09 -0400 (EDT), Mouse wrote: > >>> audioamd(4) has many assembly code (though they look very old stuff). > >> [...] I see no assembly code in arch/sparc/dev/audioamd* on 5.2 [...] > > It's in sparc/sparc/amd7930intr.s. : > Personally, I would be inclined to preserve that. It handles the > interrupt entirely in the trap window, which, for something that > interrupts frequently, can significantly lessen the impact of the > interrupts on performance. Isaki-san did not give any indication what > motivated the removal of that assembly (and presumably its replacement > with C), but I would hesitate to do it without, at the very least, > measuring the performance impact of such a change. Thank you for comment. As you said, there were too little description about this... am7930intr.s seems have been ported from C as a fast interrupt path. But it already has been disabled 11 years ago due to adapt to MI softint(9) [*]. Therefore, "asm vs C" was not a main topic here. Sorry for confusing. *: http://mail-index.netbsd.org/source-changes/2009/12/19/msg004585.html In addition, I changed the buffer structure used in interrupt handler for sharing. For these two reasons (or even if I have not changed the structure, for one reason above), to enable fast path again would require manpower. For such substitutable assembly code, unless someone continues to maintain them well, it should be removed, I personally think. > Yes, code sharing > is good - other things being equal. I suspect, though I haven't > measured it either, that "other things" are *not* equal here, that > replacing that assembly code with C (or, more precisely, the associated > potential window spilling) would have a significant impact on > performance at higher sample rates. I think that am7930 works only at 8000Hz. Does sparc's one support sample rate other than 8000Hz? Thanks, --- Tetsuya Isaki
Re: patch for am7930 audio
>>> By the way, I'm not so familiar to sparc. >>> audioamd(4) has many assembly code (though they look very old stuff). >> [...] I see no assembly code in arch/sparc/dev/audioamd* on 5.2 [...] > It's in sparc/sparc/amd7930intr.s. Ah! Personally, I would be inclined to preserve that. It handles the interrupt entirely in the trap window, which, for something that interrupts frequently, can significantly lessen the impact of the interrupts on performance. Isaki-san did not give any indication what motivated the removal of that assembly (and presumably its replacement with C), but I would hesitate to do it without, at the very least, measuring the performance impact of such a change. Yes, code sharing is good - other things being equal. I suspect, though I haven't measured it either, that "other things" are *not* equal here, that replacing that assembly code with C (or, more precisely, the associated potential window spilling) would have a significant impact on performance at higher sample rates. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: patch for am7930 audio
> > By the way, I'm not so familiar to sparc. > > audioamd(4) has many assembly code (though they look very old stuff). > > For what it's worth...I don't know what "very old" means to you, but I > see no assembly code in arch/sparc/dev/audioamd* on 5.2 (the .c > datestamped 2010, the .h, 2005). It's in sparc/sparc/amd7930intr.s. --- Izumi Tsutsui
Re: patch for am7930 audio
> By the way, I'm not so familiar to sparc. > audioamd(4) has many assembly code (though they look very old stuff). For what it's worth...I don't know what "very old" means to you, but I see no assembly code in arch/sparc/dev/audioamd* on 5.2 (the .c datestamped 2010, the .h, 2005). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
