Re: CVS commit: src/sys
At Sun, 29 Mar 2020 15:11:39 +0200, Joerg Sonnenberger wrote: > > CPU load or performance is not subject. I know that my > > implementation will work on the most modern real hardware. > > But I feel that at least 4msec is too rush to be default. > > A default should not be for one game application. > > I would allow at least 1/HZ as baseline. Thank you for comment. Using HZ sounds interesting idea, but unfortunately this will not make desired results (if what you are talking about can be written like following). #if !defined(AUDIO_BLK_MS) # define AUDIO_BLK_MS (1000 / ((HZ > 1000) ? 1000 : HZ)) #endif amd64 uses HZ=100 so that blk_ms=10. It looks good. alpha uses HZ=1024 (thanks thorpej@). If we assume upper limit HZ=1000, then blk_ms=1. It works [*] but I think that it's a bit small for default. m68k often uses HZ=60~100 so that blk_ms=10~16. This is obviously too small for m68k default. [*] On my alpha (500MHz), wss(4)/ISA works even on blk_ms=1. But I was not able to set 1msec on yds(4) PCI sound card on the same machine. Its lower limit was 5msec (due to driver's or hardware's restriction, I don't know details though). By the way, I am planning the following. How about this? dev/audio/audiodef.h #include #if !defined(AUDIO_BLK_MS) # if defined(AUDIO_BLK_MS_MACHDEP) // or better name? /* Use machine dependent default if specified */ # define AUDIO_BLK_MS AUDIO_BLK_MS_MACHDEP # else /* Otherwise use MI default */ # define AUDIO_BLK_MS (10) # endif #endif arch//include/audio_machdep.h /* Use MI default, see dev/audio/audiodef.h */ #undef AUDIO_BLK_MS_MACHDEP arch//include/audio_machdep.h #define AUDIO_BLK_MS_MACHDEP (100) // for example Thanks, --- Tetsuya Isaki
Re: CVS commit: src/sys
On Fri, Apr 03, 2020 at 09:45:20PM +0900, Tetsuya Isaki wrote: > [*] On my alpha (500MHz), wss(4)/ISA works even on blk_ms=1. > But I was not able to set 1msec on yds(4) PCI sound card on > the same machine. Its lower limit was 5msec (due to driver's > or hardware's restriction, I don't know details though). It sounds wrong to hold users hostage to the restrictions of some devices. Why does this have to be a constant anyway? It seems perfectly sensible to me that the final output device can provide a lower limit as well as having one derived from HZ and using whatever is higher. Joerg
Re: CVS commit: src/sys
At Fri, 3 Apr 2020 06:15:04 -0700, Jason Thorpe wrote: > > By the way, I am planning the following. How about this? > > I very much dislike creating an additional header file for this. Me too :) (this is why I haven't done it before) > I would prefer if the default were tuned for modern systems and overridable > by a value exported (in a namespace-appropriate way) by a header that already > exists on all platforms. What header file do you think better? Thanks, --- Tetsuya Isaki
Re: CVS commit: src/sys
On Fri, Apr 03, 2020 at 09:45:20PM +0900, Tetsuya Isaki wrote: > [*] On my alpha (500MHz), wss(4)/ISA works even on blk_ms=1. > But I was not able to set 1msec on yds(4) PCI sound card on > the same machine. Its lower limit was 5msec (due to driver's > or hardware's restriction, I don't know details though). Should we allow the driver to set a lower minimum for this? Then all m68k and vax drivers could just request (say) 100ms and we are done? Martin
Re: CVS commit: src/sys
On Fri, Apr 03, 2020 at 11:40:08PM +0900, Tetsuya Isaki wrote: > I don't think so. Each driver/hardware may have their specific > restrictions. Some driver/hardware may be able to set at 1msec > but others may not. It's nature. And this is also why we > should not be eager to reduce default blk_ms. What I meant is that the generic audio system may have a way to query the concrete driver(s) in use for a minimum value they support, and then auto-scales the blk_ms appropriately. Martin
Re: CVS commit: src/sys
At Fri, 3 Apr 2020 15:15:36 +0200, Martin Husemann wrote: > > [*] On my alpha (500MHz), wss(4)/ISA works even on blk_ms=1. > > But I was not able to set 1msec on yds(4) PCI sound card on > > the same machine. Its lower limit was 5msec (due to driver's > > or hardware's restriction, I don't know details though). > > Should we allow the driver to set a lower minimum for this? (sorry if I misunderstood your text.) I don't think so. Each driver/hardware may have their specific restrictions. Some driver/hardware may be able to set at 1msec but others may not. It's nature. And this is also why we should not be eager to reduce default blk_ms. > Then all m68k and vax drivers could just request (say) 100ms and we are > done? I don't think so. It breaks MI/MD separation (though the most drivers on m68k/vax are port-specific). It's better to handle separately "how long default blk_ms is better?" and "blocksize driver/hardware supports". Thanks, --- Tetsuya Isaki
Re: CVS commit: src/sys
> On Apr 3, 2020, at 5:45 AM, Tetsuya Isaki wrote: > > By the way, I am planning the following. How about this? I very much dislike creating an additional header file for this. I would prefer if the default were tuned for modern systems and overridable by a value exported (in a namespace-appropriate way) by a header that already exists on all platforms. -- thorpej
Re: CVS commit: src/tools/binutils
On 04.04.2020 02:47, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Apr 4 00:47:52 UTC 2020 > > Modified Files: > src/tools/binutils: mknative-binutils > > Log Message: > Handle libctf new in binutils 2.34 > > Please note that the upstreamed libctf version was not (at least when I last looked into it) compatible with what we get for CTF from other distfiles.
Re: CVS commit: src/tools/binutils
Yes, I've renamed it to libgnuctf. christos > On Apr 3, 2020, at 9:01 PM, Kamil Rytarowski wrote: > > On 04.04.2020 02:47, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sat Apr 4 00:47:52 UTC 2020 >> >> Modified Files: >> src/tools/binutils: mknative-binutils >> >> Log Message: >> Handle libctf new in binutils 2.34 >> >> > > > Please note that the upstreamed libctf version was not (at least when I > last looked into it) compatible with what we get for CTF from other > distfiles. signature.asc Description: Message signed with OpenPGP
