The 298 buffer size sounds like the "fragment" size that Boomer has
configured (about 175 Hz, but with some rounding applied, I think.)
Architecturally, it is *very* wrong for any software to rely on the
underlying buffer size (be it 1024, 298, or any other value.) The code
*should* simply read/write data as it is available, without concerning
itself with what the underlying fragment size is.
There are two ways to implement the logic correctly:
1) use ioctl() SNDCTL_DSP_GETOSPACE or SNDCTL_DSP_GETISPACE to determine
how much data can be written or read (respectively) without blocking,
and transfer that much data (or possibly less).
2) use non-blocking read/write calls, in conjunction with select or
poll, to transfer as much data as possible (limited by the amount of
data that the application can support, of course).
In neither of these cases are you looking at internal buffer sizes or
fragment sizes.
I've not looked at the code for Jack to see why it cares, but I suspect
rather strongly it is an error.
The only exceptions to caring about buffer sizes would be:
a) To get a "hint" about the latency of the audio system. (One can
assume that the framework will transfer data in chunks of whole
fragments, which implies some details about the latency your application
can expect to endure. Though even this is not guaranteed, so its only a
hint.)
b) For versions of OSS that support mmap() (Boomer doesn't at
present, but a future enhancement will add that), the sizes are
important to know so you know how much to mmap and where the pointers
wrap. However, you should still be using the SNDCTL_DSP_GETIPTR/OPTR
and SNDCTL_DSP_GETISPACE/OSPACE ioctls to determine the proper amount of
data to transfer.
-- Garrett
St?phane Letz wrote:
>
> Le 23 mars 09 ? 19:12, iurie.c at gmx.net a ?crit :
>
>> Got it working by providing "-b false" option
>> -b, --ignorehwbuf Ignore hardware period size (default: true)
>>
>> $ ./jackd -S -d oss -b false
>> jackdmp 1.9.2
>> Copyright 2001-2005 Paul Davis and others.
>> Copyright 2004-2008 Grame.
>> jackdmp comes with ABSOLUTELY NO WARRANTY
>> This is free software, and you are welcome to redistribute it
>> under certain conditions; see the file COPYING for details
>> JACK server starting in non-realtime mode
>> JackOSSDriver::OpenInput driver forced buffer size 289
>
> Fine!
>
> But this "forced buffer size 289" seems quite strange...
>
>>
>> Audio Interface Description :
>> Sampling Frequency : 48000, Sample Format : 16, Mode : 3
>> OSS product SunOS Audio
>> OSS version 4.0
>> OSS version num 262147
>> OSS numaudios 1
>> OSS numaudioengines 1
>> OSS numcards 2
>> Output capabilities - 2 channels :
>> Output block size = 1156
>> output space info: fragments = 56, fragstotal = 56, fragsize = 1156,
>> bytes = 64736
>> DSP_CAP_DUPLEX
>> OSS product SunOS Audio
>> OSS version 4.0
>> OSS version num 262147
>> OSS numaudios 1
>> OSS numaudioengines 1
>> OSS numcards 2
>> Input capabilities - 2 channels :
>> Input block size = 1156
>> input space info: fragments = 0, fragstotal = 56, fragsize = 1156,
>> bytes = 0
>> DSP_CAP_DUPLEX
>> Warning : input and output are not necessarily driven by the same clock!
>> JackOSSDriver::Write output latency frames = 577
>> JackOSSDriver::Write underruns
>> JackOSSDriver::Write underruns
>> JackOSSDriver::Write underruns
>> JackOSSDriver::Write underruns
>> JackOSSDriver::Write underruns
>> JackOSSDriver::Write underruns
>>
>> Playing sine works just fine...
>> --
>
> OK,
>
> I've not installed boomer here yet since Garrett told the interaction
> with an installed OSS 4.xx may cause some issues.
>
> Stephane_______________________________________________
> opensound-discuss mailing list
> opensound-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/opensound-discuss
