refactor: Swap %Ld for %lld in all format usages

* %Ld is an undocumented alias for %lld in glibc.
* muslc doesn't implement it for this reason.
* While we will likely never drop %Ld support,
lets clean house and set a better example.

Change-Id: Id46dad3104abae483e80cc5c05d1464d3ecd8030
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6636
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

opensound.media_addon: fixes 64 bit warnings

Enlarge the OpenSound buffer size a bit to reduce the chance of
skipping audio.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31787 a95241bf-73f2-0310-859d-f6bbb57e9c96

With the fix to the apic timer interrupts, the thread scheduling latency has
apparently vastly improved, so that audio hardware buffers can be configured
as small as on BeOS in the OSS node. This is especially nice for multi-media
apps since it reduces interactive response times.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27795 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed CID 1303. The config message was dereferenced in the constructor list.
I don't know if it can be NULL at all, but let's be defensive. It was
already checked later anyways.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27454 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Use the older fragments API for setting the driver buffer size,
since it gives much more fine grained control.
* Use a smaller buffer on Haiku, this will give some slight clicks
when something is going on (for example launching Firefox), but
should be bearable. The reduced latency is otherwise quite nice
and VLC works again which outweights the seldom clicks. Obviously
the best is to find and fix scheduler problems, but in the
meantime, this may be more helpful to people.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27382 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Cache the silence buffer instead of allocating a new one each time and
writing zeros into it in a real time thread.
* Use a different method to calculate the drift. The old method would generate
a stable drift value after some time, but somehow the drift gave problems
after a while. For example on Haiku, the MediaPlayer would stop playing
stuff after several hours of uptime. The new method calculates the drift
for just the last written buffer, like the Multi-Audio node does, but
averages the result over the last 64 drift values in order to smooth out
sudden changes. Seems to work well on Haiku, on BeOS, the sound quality seems
to be a bit worse (the BeOS mixer actually resamples each buffer according
to current drift).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26125 a95241bf-73f2-0310-859d-f6bbb57e9c96

Make the buffer latency less agressive for Haiku, this makes audio playback
perfect in Haiku for me (HD Audio), while it adds a very noticable latency.
On C-Media, the difference between "policy 4" and "policy 5" is 2048 versus
32768 bytes, which is 16 times the latency. I added a note on why the same
policy on Haiku might give me troubles (C-Media versus HD Audio means
16 bits/sample versus 32 bits/sample) and if OSS does not double the buffer
size then I can see where the trouble is comming from. I should probably
figure out a more fine grained way of influencing the driver buffer size.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26062 a95241bf-73f2-0310-859d-f6bbb57e9c96

Victory! With these changes, playback is nearly perfect under BeOS (tested with
C-Media based sound card). In Haiku, I could test with HD Audio, and playback
has clicks. It doesn't seem to have to do with the "drift", which is now
correctly published, I am not sure what exactly is causing it, I would like to
test on different hardware yet.
* I have modified the buffering policy (4 will give about 2048 bytes internal
OSS buffer), which decreases the latency of the node to an acceptable value.
* I completely replaced the timesource publishing algo to be more reliable.
* Removed now unnecessary methods from OpenSoundDeviceEngine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26059 a95241bf-73f2-0310-859d-f6bbb57e9c96

Work in progress:
* Cleaning up and refactoring the OpenSoundNode code to use a single coding
style and be less C-like in many places.
* Fixed quite a few memory leaks in OpenSoundNode.
* Removed large chunks of inactive code originating from the MultiAudioNode.
* Transfered some functionality into NodeInput and NodeOutput, could be more.
* No functional changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25932 a95241bf-73f2-0310-859d-f6bbb57e9c96

work in progress: use one thread per connected channel, and a BList of BBuffer * to avoid dropping them. Disabled early buffer recycling as latency calculation is still broken. I can now play something without missing buffers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25898 a95241bf-73f2-0310-859d-f6bbb57e9c96

gcc4 fix


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22995 a95241bf-73f2-0310-859d-f6bbb57e9c96

OpenSound System media node, current version.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22106 a95241bf-73f2-0310-859d-f6bbb57e9c96

opensound.media_addon: fixes 64 bit warnings

Enlarge the OpenSound buffer size a bit to reduce the chance of
skipping audio.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31787 a95241bf-73f2-0310-859d-f6bbb57e9c96

With the fix to the apic timer interrupts, the thread scheduling latency has
apparently vastly improved, so that audio hardware buffers can be configured
as small as on BeOS in the OSS node. This is especially nice for multi-media
apps since it reduces interactive response times.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27795 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed CID 1303. The config message was dereferenced in the constructor list.
I don't know if it can be NULL at all, but let's be defensive. It was
already checked later anyways.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27454 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Use the older fragments API for setting the driver buffer size,
since it gives much more fine grained control.
* Use a smaller buffer on Haiku, this will give some slight clicks
when something is going on (for example launching Firefox), but
should be bearable. The reduced latency is otherwise quite nice
and VLC works again which outweights the seldom clicks. Obviously
the best is to find and fix scheduler problems, but in the
meantime, this may be more helpful to people.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27382 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Cache the silence buffer instead of allocating a new one each time and
writing zeros into it in a real time thread.
* Use a different method to calculate the drift. The old method would generate
a stable drift value after some time, but somehow the drift gave problems
after a while. For example on Haiku, the MediaPlayer would stop playing
stuff after several hours of uptime. The new method calculates the drift
for just the last written buffer, like the Multi-Audio node does, but
averages the result over the last 64 drift values in order to smooth out
sudden changes. Seems to work well on Haiku, on BeOS, the sound quality seems
to be a bit worse (the BeOS mixer actually resamples each buffer according
to current drift).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26125 a95241bf-73f2-0310-859d-f6bbb57e9c96

Make the buffer latency less agressive for Haiku, this makes audio playback
perfect in Haiku for me (HD Audio), while it adds a very noticable latency.
On C-Media, the difference between "policy 4" and "policy 5" is 2048 versus
32768 bytes, which is 16 times the latency. I added a note on why the same
policy on Haiku might give me troubles (C-Media versus HD Audio means
16 bits/sample versus 32 bits/sample) and if OSS does not double the buffer
size then I can see where the trouble is comming from. I should probably
figure out a more fine grained way of influencing the driver buffer size.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26062 a95241bf-73f2-0310-859d-f6bbb57e9c96

Victory! With these changes, playback is nearly perfect under BeOS (tested with
C-Media based sound card). In Haiku, I could test with HD Audio, and playback
has clicks. It doesn't seem to have to do with the "drift", which is now
correctly published, I am not sure what exactly is causing it, I would like to
test on different hardware yet.
* I have modified the buffering policy (4 will give about 2048 bytes internal
OSS buffer), which decreases the latency of the node to an acceptable value.
* I completely replaced the timesource publishing algo to be more reliable.
* Removed now unnecessary methods from OpenSoundDeviceEngine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26059 a95241bf-73f2-0310-859d-f6bbb57e9c96

Work in progress:
* Cleaning up and refactoring the OpenSoundNode code to use a single coding
style and be less C-like in many places.
* Fixed quite a few memory leaks in OpenSoundNode.
* Removed large chunks of inactive code originating from the MultiAudioNode.
* Transfered some functionality into NodeInput and NodeOutput, could be more.
* No functional changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25932 a95241bf-73f2-0310-859d-f6bbb57e9c96

work in progress: use one thread per connected channel, and a BList of BBuffer * to avoid dropping them. Disabled early buffer recycling as latency calculation is still broken. I can now play something without missing buffers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25898 a95241bf-73f2-0310-859d-f6bbb57e9c96

gcc4 fix


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22995 a95241bf-73f2-0310-859d-f6bbb57e9c96

OpenSound System media node, current version.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22106 a95241bf-73f2-0310-859d-f6bbb57e9c96