|
|
I'm Using directsound for ogg file playback.
Also using the code I took from this website for it.
http://www.flipcode.com/archives/Ogg_Vorbis_Player_Class.shtml
It works well but I'm trying to play a 2nd music/sound file straight after the 1st finishes.
At the moment i believe the 2nd sound file plays a second just before the first finishes thus creating a rather bad mismash of a sound.
Can anyone tell me from looking at the code why this is?
The only idea I have is that it has to do with the update function and how it returns the boolean "bdone", but since I have trouble trying to understand the complex parts of code I have no idea how to fix it.
What i'm doing now is play first sound.
If the sound is finished playing (bdone=true).
play second sound.
if (flag==0)
{
oggPlayer1.Play();
flag=1;
}
if ((oggPlayer1.IsPlaying() == false) && (flag==1))
{
oggPlayer2.Play();
oggPlayer1.Close();
flag=2;
}
names have been changed from original code but it's still pretty much the same.
Thanks for any help.
|
|
|
|
|
What about:
oggPlayer1.Play();
while (oggPlayer1.IsPlaying());
oggPlayer1.Close();
oggPlayer2.Play();
while (oggPlayer2.IsPlaying());
oggPlayer2.Close();
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I'm not sure that would work.
I did try but unsuccessfully because of this:
if (flag==1)
{
oggPlayer1.Update();
}
if (flag==2)
{
oggPlayer2.Update();
}
each instance must have it's own update.
I did try usuing brackets round the while loop but it still won't work.
The changed code looks like this.
if (flag==0)
{
oggPlayer1.Play();
flag=1;
while (oggPlayer1.StoppedPlaying()==true)
{
oggPlayer1.Close();
flag=2;
}
}
if (flag==2)
{
oggPlayer2.Play();
while (oggPlayer2.StoppedPlaying()==true);
oggPlayer2.Close();
}
Doesn't even play the second file.
Though, and this is the important part, even if it did work I'm not sure it would help. The problem is not the code for playing it's the code that tells it when it stopped.
oggPlayerX.StoppedPlaying (change of name so it's easier to understand, it is true when music is stopped) returns the value true TOO early.
At least from what I can hear.
Using my old code sound 2 seems to play before sound 1 has actually finished yet obviously sound 2 only plays once the boolean StoppedPlaying returns true.
So in essence:
Sound 1 plays
StoppedPlaying returns true
Sound 2 plays
Sound 1 audibly stops a second after sound 2 starts
|
|
|
|
|
GLGunblade wrote: Doesn't even play the second file.
Maybe because flag never equals 2. I'm not sure why you are using flags anyhow. That's what the IsPlaying() method is for.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
This doesn't work.
oggPlayer1.Play();
while (oggPlayer1.StoppedPlaying())
{
oggPlayer1.Close();
oggPlayer2.Play(true);
}
if ((oggPlayer1.StoppedPlaying())==false)
{
oggPlayer1.Update();
}
if ((oggPlayer2.StoppedPlaying())==false)
{
oggPlayer2.Update();
}
How I've done it.
I used flags cause it was easier to get it working, at least it played the second sound then.
if (flag==0)
{
flag=1;
oggPlayer1.Play();
}
while (oggPlayer1.StoppedPlaying())
{
flag=2;
oggPlayer2.Play(true);
}
This works... to a point.
OggPlayer1.Close();
breaks the program and is commented out, and even when commented out the second sound doesn't even play properly.
[edit]
Just noticed that oggPlayer1.Close will contiunally get called so a flag is needed.
i.e. stoppedplaying is true and flag =1, then in that statement flag = 2 and close only gets called once without breaking the program.
I much prefer if statements since they don't give me headaches.
Why I use flags here.
StoppedPlaying will never equal to true with your code.
Since this is obviously within the update function it will continually loop past
oggPlayer1.Play()
While the sound does not reset and continues as normal, in the background the code is telling the while loop that yes it is true that sound 1 is still playing even when stopped.
I'm not sure how it keeps the sound playing without looping back on itself, I guess it's how the update function works.
Regardless without a flag it will never return false (sound has stopped playing).
Secondly this still doesn't solve the update problem, in the second example where I do use flags (And I'm pretty sure it's not flags causing my problem) and the second sound does play, though for a short period before the whole thing hangs up, the sound STILL audibly plays too early.
I apologise, I really do, you are trying to help and I really do appreciate it but even before trying your original code I never expected it to work.
Not because your code is bad or wrong, it isn't, but because it still does not change the fact that the boolean oggPlayerX.StoppedPlaying() still returns TRUE TOO early. I do not see how an if statement exchanged for a while loop would change this fact.
Unless i'm missing something huge on how a while loop and an if statement works.
modified on Friday, November 6, 2009 6:38 PM
|
|
|
|
|
Why are you calling StoppedPlaying()? Admittedly, I've never used OGG, so I don't know if the Play() method is synchronous or asynchronous.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Umm... Dunno what you mean XD
Maybe i'm using the wrong term?
when I use
oggplayer.StoppedPlaying();
is what I mean by calling it.
Though I have found the problem.
The buffer was too big, the default was 65543 * 10.
I just set it to 16000, dunno why it works but it works >_>
Maybe it reads the buffer as one huge section and when it reaches the last section it returns stopped even though there's still a bit to play left.
|
|
|
|
|
Hi
I want to write code that is executed in all instances of explorer.exe. Then it will look for specific Explorer controls, subclass them, tweak them, etc.
I tried a shell extension but they are only activated under certain conditions - right click on a file, drag/drop, etc. I tried a namespace extension, but it added an ugly icon on the desktop.
Any ideas how to do that correctly?
Thanks
Ivo
|
|
|
|
|
If the namespace extension can do what you want to do, then you must simply figure out a way to get rid of the ugly desktop icon.
This is much safer than injecting code, especially into explorer.exe
|
|
|
|
|
Well, I did delete the icon, I got a message "blah, blah, you can restore it later from Control Panel" and now my DLL doesn't get loaded... I have no idea where in the Control Panel I can go to get my icon back.
Are there any other shell extensions that load at startup?
|
|
|
|
|
can anyone help me doing d graphics design for butterfly in c or turbo c++
|
|
|
|
|
|
Hello everybody,
is it possible to clone the "not-stealing-modus" behaviour of a context-menu?
I open a modal dialog in a MDI application. Causing this modal state, the mainframe looses his
focus and the shadow at the outer-border reduses to a smaller shadow (in Vista).
Is it possible to open a modal dialog and to keep the full-shadow on the mainframe, like it happens to a standard context-menu?
Big thanks for any help 
Greetings
|
|
|
|
|
baerten wrote: Is it possible to open a modal dialog and to keep the full-shadow on the mainframe, like it happens to a standard context-menu?
This is a function of your Windows Appearance settings. When a modal dialog is opened it becomes the active window, and the owner of the dialog now becomes inactive and its appearance is modified accordingly. I think the only way to change this would be to use custom settings for your windows.
|
|
|
|
|
thanks for your answer.
I'll try to find another workaround to fix this "problem"
if i can't find a solution, i drop it 
|
|
|
|
|
Hi guys, I am just wondering how to implement a dialog I have made in Microsoft C++ 6.0
So I created a C++ project, then added a .rc script file. Then I added a new item to it (dialog control, called IDD_MENU) Now, I am wondering how would I use this menu inside my code? I have worked with WINAPI and spent hours coding GUIS. Just yesterday I downloaded C++ 6.0 (my new compiler, instead of Code::Blocks) and I am wondering how would I use the GUI I created? I have tried implementing it the same way I usually do for WINAPI, but this did not work. How do I do this? I have searched google for 1 day now, and I have not found anything. Hopefully somebody could help me out on this.
|
|
|
|
|
PimpDawg wrote: Hi guys, I am just wondering how to implement a dialog I have made in Microsoft C++ 6.0
Use CreateDialog() for modeless, and DialogBox() for modal.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I recommend you use MFC.
It is a good framework for creating UI applications.
|
|
|
|
|
If are just starting with Visual C++ why not choose a newer version. Visual Studio Express[^] editions are free.
-Saurabh
|
|
|
|
|
How do I get the handle to the Windows desktop
I dont think GetDesktopWindow returns the handle to the Windows desktop
Thanks
Sujay
|
|
|
|
|
sujayg wrote: I dont think GetDesktopWindow returns the handle to the Windows desktop
Documentation says that it does. [^]
Nuri Ismail
|
|
|
|
|
sujayg wrote: dont think GetDesktopWindow returns the handle to the Windows desktop
MSDN [^]:
The GetDesktopWindow function returns a handle to the desktop window.
I see a conflict... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hello Ian,
Yes the name is a bit confusing. The desktop handle is the main WIndow on top of which all Windows are painted .
But it does not return the handle of the Window ( SysListView32 ) - which is the WIndows desktop .
This can be checked with Spy++
There is another function, GetShellWindow, which "probably" returns the Windows desktop handle, I am testing that
Sujay
|
|
|
|
|
sujayg wrote: But it does not return the handle of the Window ( SysListView32 )
that list view is not the desktop window, it is a child of a child of the desktop.
you can verify that with Spy++ by looking at the ID of the Desktop window as shown in the default window list compared to the ID of that list view.
the listview is a child of the Program Manager, which is the Windows Shell.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
