Rework nodes to call Run() only after registration

* While it should not be a big problem the
bebook specify to do it after custom operations,
most nodes also follow this way, this commit restore
consistency.

MediaPlayer: some 64 bit fixes

Removed no longer useful debug output.


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

Always wait for buffers in AudioProducer::_FillNextBuffer().
Seems to work around a problem in the system mixer. When it
happens once that the AudioProducer does not send a buffer,
then it can eventually lead to a drop into the debugger
from BBuffer::SetHeader(), which to me looks like the BMediaEventLooper
thread of the mixer still runs when the System Mixer has been
shut down, which itself is yet another problem. I shall
investigate, but for the time being, one should enjoy a more
stable media_addon_server life-time.


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

ERROR->TRACE for LateNoticeReceived()


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

One should be suspicious when subtracting "samples"
from "frames". LateNoticeReceived() would have skipped
two many buffers depending on the channel count.


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

* _FillNextBuffer(): performanceTime and startTime were duplicated variables.
* Small coding style improvements.
* Improved generating of debug .wav file.
* Incorporate the channel count in the audio buffer size! This was important
since the duration could then lead to rounding errors. 6 channel playback
is much improved, but still far from perfect.


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

Print the FillBuffer() error when running out of buffers only once.


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

* We now limit the maximum latency in MediaPlayer and the audio mixer, as a
latency can easily get annoying if too high.


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

* The AudioProducer now correctly handles late producer notices by ignoring
extra notices for buffers already scheduled.
* Also, the AudioSupplier/AudioReader classes now know their initial latency,
and the AudioProducer is now using that one to advertize its own initial
latency - this fixes late buffers on start, causing the latency to grow
too large.
* Cleanup here and there.


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

* A BBuffer does not know where it came from, so
BBufferConsumer::BufferReceived() cannot know whom to send the "buffer is
late" notification (unless we only have a single input). To solve this, the
media_header now contains extra fields that can be used to create a
media_source object.
* Unfortunately, BBufferProducer::SendBuffer() cannot know the output either in
case there is more than one. Hence, I deprecated the existing SendBuffer()
call and moved it into "private" - IOW old sources using it won't compile
anymore under Haiku.
* I introduced a new SendBuffer() variant that also gets the media_source as
argument.
* Updated all sources (that are part of the image) to use the new variant.
* Removed some purposely commented out code in the audio mixer.
* Implemented late buffer notification, as well as late buffer handling in the
audio mixer; this is a bit of work in progress, so the debug output is left
in there.
* Some cleanup.


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

Disabled tracing again.


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

All sorts of refactoring with regards to the audio node and format setup. At
first I tried adding support for changing the format during running the node
connection, but later found out that this is not implemented in the system
mixer (it has this weird setting to allow input format changes, but if you
do this, the media_server will just crash, since the backend does not support
it yet). Also, the Media Kit documentation is extremely lacking in this regard.
I ended up re-establishing the node connection when the audio format is
supposed to change, just like it is already done for video. This means that
audio files now play with their native channel count and frame rate. But it
isn't so well tested yet, if 48 kHz for example introduce some clicks. The
channel count should not be a problem though, I've also tested that with some
movies and it works fine.


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

Fixed hardcoded AudioProducer output name.
Stephan, Axel, could one of you report this change in clockwerk/src/shared/AudioProducer.cpp too.
Clockwerk name his audio output "MediaPlayer Sound Output", which is both confusing and, well,
semantically wrong ;-).

BTW, for MediaPlayer being able to (re)name his output after the filename playing will be great, no?


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

Removed left-over debug output.


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

* Basically, the audio buffer size was simply too small and caused
audio playback with frequent glitches. I am testing with HDA and have
perfect audio now. The only remaining problem is the drop-sample
resampling in the system mixer, which gives a somewhat metallic sound.
* Removed hardcoded values from preferred format and used them if
the consumer supplies wildcard values. Since the system mixer supplies
wildcards for all those values, this change does not have any effect
for now. The code is more correct, though.


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

Remove the negative delay that was supposed to account for client->app_server
delay. The audio is later than the calculated realtime anyways, I suspect
the OSS Node does not advertise it's latency 100% correctly yet.


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

Fix scope for gcc4.


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

That is more likely to give the right realtime...


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

* The SeekSlider did not update the knob when it was resized.
* Subtile visual improvements to the SeekSlider.
* Added a PeakView for displaying the audio peaks that are produced by
the AudioProducer.
* A MessageEvent can now directly take a custom BMessage for delivery.
* The peak notification mechanism is a bit separate from the rest of the
Controller notification design, since the notification delivery should
be delayed until the audio is actually audible. I may change this
quick and dirty design though, since it is not so nice. The target
time could also be part of the message and be handled at a different
stage, but that would make it less efficient.
* Layout improvements to the playback controls.
* Code cleanup here and there, changed some license statements.


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

Minor changes to debug output, I was trying to track something down, actually
a problem in the OSS media node which also affects at least the ZETA 1.2
MediaPlayer on ZETA.


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

Small code cleanups.


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

* Moved a bunch of non-primary interface classes into a new subfolder
"interface"

* Complete reimplementation of the playback engine using Media Nodes:
- Seeking video files does not appear to lockup the playback anymore, but
works on a frame accurate level even for keyframe based streams. There is
currently a problem with certain container formats, the audio track reports
a "Device Seek Error" in certain conditions. In that case audio goes silent,
and can be restarted by going back to the beginnings of the stream.
- Video overlays are now supported.
- It would be possible to connect the output of the MediaPlayer to other
applications or dormant media nodes.

* Known regressions:
- The volume slider has currently no effect anymore.
- Switching the audio track during playback has a known race condition and
can crash the player.
- The new engine is not as "light weight" as the old one. I tagged the
previous implementation in tags/components/mediaplayer-engine-v1. It does
not seem to have any noticable effect though.



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

Rework nodes to call Run() only after registration

* While it should not be a big problem the
bebook specify to do it after custom operations,
most nodes also follow this way, this commit restore
consistency.

MediaPlayer: some 64 bit fixes

Removed no longer useful debug output.


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

Always wait for buffers in AudioProducer::_FillNextBuffer().
Seems to work around a problem in the system mixer. When it
happens once that the AudioProducer does not send a buffer,
then it can eventually lead to a drop into the debugger
from BBuffer::SetHeader(), which to me looks like the BMediaEventLooper
thread of the mixer still runs when the System Mixer has been
shut down, which itself is yet another problem. I shall
investigate, but for the time being, one should enjoy a more
stable media_addon_server life-time.


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

ERROR->TRACE for LateNoticeReceived()


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

One should be suspicious when subtracting "samples"
from "frames". LateNoticeReceived() would have skipped
two many buffers depending on the channel count.


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

* _FillNextBuffer(): performanceTime and startTime were duplicated variables.
* Small coding style improvements.
* Improved generating of debug .wav file.
* Incorporate the channel count in the audio buffer size! This was important
since the duration could then lead to rounding errors. 6 channel playback
is much improved, but still far from perfect.


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

Print the FillBuffer() error when running out of buffers only once.


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

* We now limit the maximum latency in MediaPlayer and the audio mixer, as a
latency can easily get annoying if too high.


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

* The AudioProducer now correctly handles late producer notices by ignoring
extra notices for buffers already scheduled.
* Also, the AudioSupplier/AudioReader classes now know their initial latency,
and the AudioProducer is now using that one to advertize its own initial
latency - this fixes late buffers on start, causing the latency to grow
too large.
* Cleanup here and there.


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

* A BBuffer does not know where it came from, so
BBufferConsumer::BufferReceived() cannot know whom to send the "buffer is
late" notification (unless we only have a single input). To solve this, the
media_header now contains extra fields that can be used to create a
media_source object.
* Unfortunately, BBufferProducer::SendBuffer() cannot know the output either in
case there is more than one. Hence, I deprecated the existing SendBuffer()
call and moved it into "private" - IOW old sources using it won't compile
anymore under Haiku.
* I introduced a new SendBuffer() variant that also gets the media_source as
argument.
* Updated all sources (that are part of the image) to use the new variant.
* Removed some purposely commented out code in the audio mixer.
* Implemented late buffer notification, as well as late buffer handling in the
audio mixer; this is a bit of work in progress, so the debug output is left
in there.
* Some cleanup.


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

Disabled tracing again.


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

All sorts of refactoring with regards to the audio node and format setup. At
first I tried adding support for changing the format during running the node
connection, but later found out that this is not implemented in the system
mixer (it has this weird setting to allow input format changes, but if you
do this, the media_server will just crash, since the backend does not support
it yet). Also, the Media Kit documentation is extremely lacking in this regard.
I ended up re-establishing the node connection when the audio format is
supposed to change, just like it is already done for video. This means that
audio files now play with their native channel count and frame rate. But it
isn't so well tested yet, if 48 kHz for example introduce some clicks. The
channel count should not be a problem though, I've also tested that with some
movies and it works fine.


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

Fixed hardcoded AudioProducer output name.
Stephan, Axel, could one of you report this change in clockwerk/src/shared/AudioProducer.cpp too.
Clockwerk name his audio output "MediaPlayer Sound Output", which is both confusing and, well,
semantically wrong ;-).

BTW, for MediaPlayer being able to (re)name his output after the filename playing will be great, no?


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

Removed left-over debug output.


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

* Basically, the audio buffer size was simply too small and caused
audio playback with frequent glitches. I am testing with HDA and have
perfect audio now. The only remaining problem is the drop-sample
resampling in the system mixer, which gives a somewhat metallic sound.
* Removed hardcoded values from preferred format and used them if
the consumer supplies wildcard values. Since the system mixer supplies
wildcards for all those values, this change does not have any effect
for now. The code is more correct, though.


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

Remove the negative delay that was supposed to account for client->app_server
delay. The audio is later than the calculated realtime anyways, I suspect
the OSS Node does not advertise it's latency 100% correctly yet.


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

Fix scope for gcc4.


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

That is more likely to give the right realtime...


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

* The SeekSlider did not update the knob when it was resized.
* Subtile visual improvements to the SeekSlider.
* Added a PeakView for displaying the audio peaks that are produced by
the AudioProducer.
* A MessageEvent can now directly take a custom BMessage for delivery.
* The peak notification mechanism is a bit separate from the rest of the
Controller notification design, since the notification delivery should
be delayed until the audio is actually audible. I may change this
quick and dirty design though, since it is not so nice. The target
time could also be part of the message and be handled at a different
stage, but that would make it less efficient.
* Layout improvements to the playback controls.
* Code cleanup here and there, changed some license statements.


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

Minor changes to debug output, I was trying to track something down, actually
a problem in the OSS media node which also affects at least the ZETA 1.2
MediaPlayer on ZETA.


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

Small code cleanups.


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

* Moved a bunch of non-primary interface classes into a new subfolder
"interface"

* Complete reimplementation of the playback engine using Media Nodes:
- Seeking video files does not appear to lockup the playback anymore, but
works on a frame accurate level even for keyframe based streams. There is
currently a problem with certain container formats, the audio track reports
a "Device Seek Error" in certain conditions. In that case audio goes silent,
and can be restarted by going back to the beginnings of the stream.
- Video overlays are now supported.
- It would be possible to connect the output of the MediaPlayer to other
applications or dormant media nodes.

* Known regressions:
- The volume slider has currently no effect anymore.
- Switching the audio track during playback has a known race condition and
can crash the player.
- The new engine is not as "light weight" as the old one. I tagged the
previous implementation in tags/components/mediaplayer-engine-v1. It does
not seem to have any noticable effect though.



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