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
* RealTimeForTime() did not work without VideoProducer. Maybe it is never
used though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26141 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
a volume to the audio data. It ramps between a previous and the current volume
if necessary to smooth out the changes. The volume slider functionality is
thereby restored.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26066 a95241bf-73f2-0310-859d-f6bbb57e9c96
include the OSS media add-on (node), since Haiku comes with it's own
version. Therefor you can now add the OpenSound optional package and
it will just work out of the box, unless you have native drivers that
fight over the hardware with OSS. It is no longer necessary to delete
the opensound.media_addon from the home/config/add-ons/media folder.
If you don't build from scratch, make sure you delete
generated/download/OpenSound.zip or the change won't take effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26064 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
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
the scrollbar.
* Added notes about BeOS behavior to SetTarget(const char*).
* Reuse SetTarget(NULL) in the destructor.
* Initialize fTarget and fTargetName in the archive constructor.
* Added TODO about possibly restoring the target in the archive constructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26057 a95241bf-73f2-0310-859d-f6bbb57e9c96
been requested. The first call to a BView::Invalidate() will flush the link
so that app_server is notified as soon as possible. It makes no sense for
further calls to Invalidate() to flush also, since Flush() is not cheap. This
trick makes Invalidate() about 3.2 times faster, making it a cheaper operation.
I could not see any negative effects, I tested with apps that invalidate
multiple different parts inside a window in reaction to something. Thanks go to
Ingo who had the idea.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26020 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The audio and video panes refered to the OS as "BeOS", now it's "Haiku".
Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25936 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
only the decoder structure is now initialized per instance, this should
be better (thread safe).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25925 a95241bf-73f2-0310-859d-f6bbb57e9c96
session to also include each view's individual update rect (in screen coords).
Should actually not be mush slower than the old version, and hopefully makes
it possible to have smarter BView::Draw() implementations which should make
more than up for any potential speed loss.
* Removed unused version of View::AddTokensForViewsInRegion().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25879 a95241bf-73f2-0310-859d-f6bbb57e9c96
play any more clips." Of course I was searching in my own commits. In the
end, I resorted to binary searching revisions for when this broke. Turns out
it is your change r25793/r25794, in which you forgot to attach the colorspace
to the app_server message. Which of course makes it lock up. Another of those
instances where you think passing data structures between client and app_server
instead of this "protocol" would be the better idea...
* Fixed bitmaps_support_space() retrieving the currently supported overlay
flags for a given color space. This makes MediaPlayer play files again, the
media node connection would time out because of the broken app_server
communication. (I have not tested this change yet, but I will in a minute, on
a different computer.)
* Also retrieve the overlay supported flag for YCbCr colorspaces.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25847 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Slightly more debug output for failed atempts to create a decoder.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25825 a95241bf-73f2-0310-859d-f6bbb57e9c96
* On BeOS "bitmaps_support_space()" returns false for YCbCr color spaces. :-(
* Refactor the code which sets up the decoded format in the MediaTrack-
VideoSupplier to always start with a clean format for multiple calls to
BMediaTrack::DecodedFormat().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25824 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Do not exit in case of success to retry with B_RGB32, so the bytes per row
check is performed.
* Ignore if bytes per row is big enough.
* Check the success for the last attempt to set DecodedFormat().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25821 a95241bf-73f2-0310-859d-f6bbb57e9c96
end, this results in trying to decode the last frame again, which would
the decoder to seek unnecessarily.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25820 a95241bf-73f2-0310-859d-f6bbb57e9c96
zero, otherwise we leak these plugins, since the ref counting is based
on the plugin still being in the list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25792 a95241bf-73f2-0310-859d-f6bbb57e9c96
In the end, the problem was that no codec was installed
for it, but I fixed a bunch of issues on the way to find
out. Now the controller will not rely on the number
of audio and video tracks, but on the fact that it could
instantiate suppliers at all. Made the MediaTrackVideoSupplier
return an init error. Should be replicated for the
MediaTrackAudioSupplier.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25765 a95241bf-73f2-0310-859d-f6bbb57e9c96
bitmaps_support_space() interface kit function. First try to
use overlays, if that fails, try again without overlays. The
NodeManager makes sure to fall back to B_RGB32 if the given
mode is not supported for drawing bitmaps in by BViews. Thanks,
Axel, for the suggestion!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25764 a95241bf-73f2-0310-859d-f6bbb57e9c96
bitmap support (bitmaps support child views or BViews can
draw them)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25762 a95241bf-73f2-0310-859d-f6bbb57e9c96
either, it just hangs there trying ot connect and eventually times out.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25751 a95241bf-73f2-0310-859d-f6bbb57e9c96
regression that audio playback of multiple files was not "seamless" anymore.
Even video playback should be seamless, the remaining small glitch could be
a problem with buffer timeout if the switch takes too long.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25735 a95241bf-73f2-0310-859d-f6bbb57e9c96
the producer media nodes would access the suppliers in their own thread
without having any locks held, while the window could replace the suppliers.
I think since I delayed the deletion of the suppliers in the controllers, this
problem was only theoretical... but this is just more clean.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25734 a95241bf-73f2-0310-859d-f6bbb57e9c96
a way that the transport group did not need to re-layout, then the seek
slider would not be at the correct position.
* Layout the transport controls with a fixed maximum width in order to prevent
spreading them too much.
* Fix "About" and "MediaPlayer" missing a space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25733 a95241bf-73f2-0310-859d-f6bbb57e9c96
displayed, does not seem to be the reason for the problem I am observing
with one clip I have, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25732 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Leave the codec a chance to advertise the best output color space,
try B_YCbCr422 as the most widely supported format in case the codec
does not advertise.
* Support two more overlay colorspace modes in the video consumer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25731 a95241bf-73f2-0310-859d-f6bbb57e9c96
"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
part of headers/private/shared, Icon-O-Matic used older versions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25720 a95241bf-73f2-0310-859d-f6bbb57e9c96
help with bugs, sending patches and the ongoing Haiku-Ports effort.
As always, if you think someone should be listed, please drop me a line!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25711 a95241bf-73f2-0310-859d-f6bbb57e9c96
packages. Print an error message for unavailable packages.
* Detect the build of a GCC2/GCC4 hybrid image and install GCC2 packages
on a GCC4 build where no GCC4 package is available. I did not test
every GGC2 package on a GCC4 build, though I have not found any that
does not work. If a package gives problems, feel free to disable it
for the hybrid build or send me a note.
* Add new optional package for Beam. Though I could not test it since,
SATA AHCI does not work for me ATM. I know that Beam 1.1 for BONE is
unable to retrieve mails (times out). Maybe the R5 version has better
luck, will check later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25695 a95241bf-73f2-0310-859d-f6bbb57e9c96
Our font has some extra styles and these could be picked up as the
"regular" face by accident, as witnessed by Firefox. Tracked down by
Michael Lotz. Firefox uses the correct font now for it's interface.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25636 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added "struct" to ancillary_data_container which fixes the build of the
Bluetooth h2generic driver.
---
* Updated license header.
* Honour 80 char line width.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25606 a95241bf-73f2-0310-859d-f6bbb57e9c96
transform only, not combined with the shapes own scale, since that is likely
not what the user intended.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25521 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use find_directory() for the hash for preloaded modules. I am not sure this
patch is needed, since it only concerns the hash. Please review.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25511 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed main.c to main.cpp
* Use find_directory() to construct the Bootscript path.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25509 a95241bf-73f2-0310-859d-f6bbb57e9c96
Use find_directory() to find the runtime_loader when starting teams.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25506 a95241bf-73f2-0310-859d-f6bbb57e9c96
message correctly, it is a bit strange why the message should not follow
protocol.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25499 a95241bf-73f2-0310-859d-f6bbb57e9c96
properly credit James Woodcock, who debugged this problem and whom I forgot
to mention in my previous commit. Sorry!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25495 a95241bf-73f2-0310-859d-f6bbb57e9c96
_ArgvReceived(), the array elements still need to be set to NULL otherwise
the function will free() random pointers at the end.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25494 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added a new command line utility "mkfs" which can initialize a given volume
with a file system by it's short name via the new Disk Device API.
Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25491 a95241bf-73f2-0310-859d-f6bbb57e9c96
the internal enumaration for GetNextDiskSystem(). The compiler spotted that
one actually... :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25490 a95241bf-73f2-0310-859d-f6bbb57e9c96
(including any drag bitmap). HWInterface::HideFloatingOverlays() was plain
stupid, I know it did check double buffering at one point, but I must have
removed that when messing with it. But copying anything from back to front
buffer is now not overwriting the cursor area anymore, which is painted
immediatly afterwards. Also moving the cursor invalidates only one rect
if old and new cursor area overlap. All these changes should save some cycles
too. Added TODO with regard to caching the on-the-fly cursor compositing
buffer.
If you have
* a more recent computer
* a decent VESA BIOS which supports your native resolution
* don't need video overlays
... I recommend using the VESA driver.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25479 a95241bf-73f2-0310-859d-f6bbb57e9c96
find the DeskCalc icon, we need to use BRoster::FindApp() instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25477 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Extended the scope of the Revert feature to include changes to the time zone.
* Moved the Revert button out of the tab view, so that it indicates the above
visually. The window now handles the Revert feature.
* Added Others/Greenwhich time zone which is equivalent to an "unset" time zone.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25415 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed Track and Disc time labels to be large enough. (Fixes #2201.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25412 a95241bf-73f2-0310-859d-f6bbb57e9c96
may take a short moment on real hardware, it is better than the "Asking blah
to quit..." which is otherwise still left.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25355 a95241bf-73f2-0310-859d-f6bbb57e9c96
a "snowman" icon for BSnow (big snowballs, coals for eyes, carrot...) but have
not found the time yet. Meanwhile and I agree that his icon is much better than
the previous one in any case. :-) (Hope you don't take offense, Francois!)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25341 a95241bf-73f2-0310-859d-f6bbb57e9c96
The NetworkStatus applet is now able to launch the Network preferences via
its contex menu.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25329 a95241bf-73f2-0310-859d-f6bbb57e9c96
application. NOTE: Using FileTypes within Haiku to set this properties
does not result in other applications to be able to use BRoster::Launch()
with the given signature. The error message will change from "Application
not found" to "No application found to handle this file type" (or the like).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25328 a95241bf-73f2-0310-859d-f6bbb57e9c96
this (seems to be what R5 BStatusBar does):
* combine the "trailing text" with the "trailing label" and truncate the
resulting string on the left side according to the width of the entire
control
* combine the "label" with the "text" and truncate that on the right side
according to the space left by the right hand text.
-> No more overlaps (theoretically, in practise there are still overlaps
because our BFont::TruncateString() does not respect the width in some
situations.)
* Changed _SetTextData() accordingly, it is not used anymore for the
label and trailing label, and could therefor be simplified a little.
* fixed _BarFrame() to not return fractional coords, which could sometimes
leave a dirty line of pixels.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25244 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Pick 8 random icons from the application and preference folders
* Pick 8 different icons when the game starts again
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25224 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan Aßmus