[DSOUND] add DirectSoundFullDuplex support

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[DSOUND] add DirectSoundFullDuplex support

Robert Reif
Add DirectSoundFullDuplex support.

This patch is rather large because it was necessary to refactor the
existing code so it could be used by the full duplex code.  Most of
the changes are either changing all the code to use the lower level
device objects rather than the higher level COM objects or moving
code and renaming variables  to make things easier to follow.
This has the benefit of removing one level of indirection for a lot
of code.  With this refactoring, it was very easy to add the full
duplex support.

There should be no functional changes to capture and playback
other than a slight speed improvement due to one less level of
indirection for accessing most variables.




duplex.diff.gz (42K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Vitaliy Margolen-2

Thursday, October 13, 2005, 6:06:33 PM, Robert Reif wrote:

> Add DirectSoundFullDuplex support.

> This patch is rather large because it was necessary to refactor the
> existing code so it could be used by the full duplex code.  Most of
> the changes are either changing all the code to use the lower level
> device objects rather than the higher level COM objects or moving
> code and renaming variables  to make things easier to follow.
> This has the benefit of removing one level of indirection for a lot
> of code.  With this refactoring, it was very easy to add the full
> duplex support.

> There should be no functional changes to capture and playback
> other than a slight speed improvement due to one less level of
> indirection for accessing most variables.

1. Don't send patches in gz - only plain text is accepted here. ;)
2. This is not a good time for this changes (code freeze is still in affect).

Find some bugs in bugzilla to fix <g>

Vitaliy.



Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Robert Reif
Vitaliy Margolen wrote:

>1. Don't send patches in gz - only plain text is accepted here. ;)
>2. This is not a good time for this changes (code freeze is still in affect).
>
>Find some bugs in bugzilla to fix <g>
>
>Vitaliy.
>
I guess I could have split it up into half a dozen patches.

This is something I needed for work so I took the opportunity to
do some wine hacking.  I'm way to busy to do much more than
just reading the mailing lists now and I don't see that changing
for the next 6 months.  This can wait until after 0.9.  It's out there
now for anyone that is interested.

I do most of my development on RH9 for RH9 and most
of the sound related bugs and missing features are either ALSA
related (even OSS emulation in ALSA) or scheduler related and
I don't have the time or resources to tackle big issues like these
now.



Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Jonathan Ernst
Le jeudi 13 octobre 2005 à 21:29 -0400, Robert Reif a écrit :

> I guess I could have split it up into half a dozen patches.
>
> This is something I needed for work so I took the opportunity to
> do some wine hacking.  I'm way to busy to do much more than
> just reading the mailing lists now and I don't see that changing
> for the next 6 months.  This can wait until after 0.9.  It's out there
> now for anyone that is interested.
>
> I do most of my development on RH9 for RH9 and most
> of the sound related bugs and missing features are either ALSA
> related (even OSS emulation in ALSA) or scheduler related and
> I don't have the time or resources to tackle big issues like these
> now.
Your patch look very good to me (but i'm not an expert). If nobody
thinks that it has issues, maybe you could resend it uncompressed and
splitted into two or more parts (at least separate the refactoring part
and the full duplex part). Then Alexandre will decide if it can be
applied before or after the 0.9 release.

Thanks !



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Molle Bestefich
In reply to this post by Vitaliy Margolen-2
Vitaliy Margolen wrote:
> 2. This is not a good time for this changes (code freeze is still in affect).
>
> Find some bugs in bugzilla to fix <g>

I'm getting a sick feeling to my stomach here.
Maybe I'm just misunderstanding things?

You're rejecting a perfectly fine patch to Wine, because
it's the wrong season of the year to send good patches?

What was wrong with doing what everyone else does -
 - create a branch for the up-and-coming release,
 - keep applying good patches to trunk,
 - cherry pick *very* important patches (clean bugfixes) and merge
them to the branch?

?

People tell me that Wine are always two steps behind.
Doesn't surprise a lot, if perfectly fine patches are rejected from
entering development trunk.

What's the idea here, to make sure that CrossOver and Cedega are
always a good step ahead?  Do they have too little business value to
keep sales up if Wine is allowed to develop too fast?  Or what's going
on?


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

MediaHost (TM)
Molle Bestefich wrote:
I'm getting a sick feeling to my stomach here.
Maybe I'm just misunderstanding things?

You're rejecting a perfectly fine patch to Wine, because
it's the wrong season of the year to send good patches?

People tell me that Wine are always two steps behind.
Doesn't surprise a lot, if perfectly fine patches are rejected from
entering development trunk.

What's the idea here, to make sure that CrossOver and Cedega are
always a good step ahead?  Do they have too little business value to
keep sales up if Wine is allowed to develop too fast?  Or what's going
on?
Which is actually quite an interesting question...I mean, Wine is quite good and works
for many applications, but what is the business model of CrossOver and others, when
and if Wine gets so good and CrossOver isn't needed anymore?

Does CrossOver have a plan, such as offering services, instead of selling CrossOver?
And because Wine is licensed under LGPL (correct me if I'm wrong!!), it allows CrossOver
and others to develop and sell their implementations of Wine, without submitting back patches
to the Wine sources.

I don't mean to attack here CrossOver and it's widely known, that CrossOver's support of Wine,
including patches, is great! But some clarification would be in place...


Regards
 
Signer:      Eddy Nigg
Company: StartCom Linux at
www.startcom.org
                MediaHost™ at www.mediahost.org
Skype:      <a href="callto://startcom/">startcom
Phone:      +1.213.341.0390
 






smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: add DirectSoundFullDuplex support

Dan Kegel-3
In reply to this post by Molle Bestefich
On 10/14/05, Molle Bestefich <[hidden email]> wrote:

> Vitaliy Margolen wrote:
> > 2. This is not a good time for this changes (code freeze is still in
> affect).
> >
> > Find some bugs in bugzilla to fix <g>
>
> I'm getting a sick feeling to my stomach here.
> Maybe I'm just misunderstanding things?
>
> You're rejecting a perfectly fine patch to Wine, because
> it's the wrong season of the year to send good patches?

No, just deferring it.

> What was wrong with doing what everyone else does -
>  - create a branch for the up-and-coming release,
>  - keep applying good patches to trunk,
>  - cherry pick *very* important patches (clean bugfixes) and merge
> them to the branch?

Go look at what the Linux Kernel and the gcc projects
*actually* do.   Both projects actually do have this kind
of code "slush" periodically.   Active development continues
during the slush periods, but the resulting patches just sit
in the developers' trees until after the slush is over.

It's ok, really.
- Dan


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Vitaliy Margolen-2
In reply to this post by Molle Bestefich
Friday, October 14, 2005, 5:24:40 AM, Molle Bestefich wrote:
> Vitaliy Margolen wrote:
>> 2. This is not a good time for this changes (code freeze is still in affect).
>>
>> Find some bugs in bugzilla to fix <g>

> I'm getting a sick feeling to my stomach here.
> Maybe I'm just misunderstanding things?
I think you do.

> You're rejecting a perfectly fine patch to Wine, because
> it's the wrong season of the year to send good patches?
I have no power to accept nor reject path. All I'm trying to say, is that right
now (Oct 14 2005) Wine is in a "code freeze" (see announcement about that few
weeks ago). That announcement stated that only "small bug fixes" or other well
warranted "small changes" will go in until after Wine 0.9 is out. And they will
probably get lost and will have to be resent.

Don't get me wrong here - I am excited as you are about some one working on
dsound. It's just a wrong time to send this huge patches in.

Also if you haven't looked, there are lots of open bugs in bugzilla that sooner
or later have to be fixed.

Vitaliy







Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Molle Bestefich
Vitaliy Margolen wrote:
> > You're rejecting a perfectly fine patch to Wine, because
> > it's the wrong season of the year to send good patches?
> I have no power to accept nor reject path. All I'm trying to say, is that right
> now (Oct 14 2005) Wine is in a "code freeze" (see announcement about that few
> weeks ago). That announcement stated that only "small bug fixes" or other well
> warranted "small changes" will go in until after Wine 0.9 is out. And they will
> probably get lost and will have to be resent.


>
> Don't get me wrong here - I am excited as you are about some one working on
> dsound. It's just a wrong time to send this huge patches in.
>
> Also if you haven't looked, there are lots of open bugs in bugzilla that sooner
> or later have to be fixed.

Ok, I did misunderstand a bit, but also you didn't answer my main question.
I'll just ask it again, hope it's ok:

Why not do this:
  Accept the patches into trunk, and do the "code freeze" in a branch.

Pros:
 - Developers of patches will not get pissed (ahem) for their stuff
not getting in.
 - Development doesn't stop just every time a release is coming up.
 - Developers can actively select whether they'd like to help with the
release (switch to '0.9-rc' branch) or do a little more crazy stuff
(switch to trunk).
 - Only sane patches get accepted to the RC by picking and merging
those that are approved some way or another.
 - Patches don't get "LOST" as you call it..

Cons:
 - Can't think of any?


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Molle Bestefich
Molle Bestefich wrote:

> Pros:
>  - Developers of patches will not get pissed (ahem) for their stuff
> not getting in.
>  - Development doesn't stop just every time a release is coming up.
>  - Developers can actively select whether they'd like to help with the
> release (switch to '0.9-rc' branch) or do a little more crazy stuff
> (switch to trunk).
>  - Only sane patches get accepted to the RC by picking and merging
> those that are approved some way or another.
>  - Patches don't get "LOST" as you call it..
>
> Cons:
>  - Can't think of any?

Ok, maybe there's one.  You need a release manager to pick which
patches gets in the RC / release.

But there must be a million ways of doing that automatically, besides
from having an actual release manager.  Script your way out of it.
Automatically merge patches with 'bugfix' or 'Release-Ok' in commit
text.  Automatically merge patches < 100 lines long.  Hohum.
Whatever.  I can think of more, I'm sure you can too.


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Evil Jay
In reply to this post by Molle Bestefich
Molle Bestefich wrote:

>Why not do this:
>  Accept the patches into trunk, and do the "code freeze" in a branch.
>
>Pros:
> - Developers of patches will not get pissed (ahem) for their stuff
>not getting in.
> - Development doesn't stop just every time a release is coming up.
> - Developers can actively select whether they'd like to help with the
>release (switch to '0.9-rc' branch) or do a little more crazy stuff
>(switch to trunk).
> - Only sane patches get accepted to the RC by picking and merging
>those that are approved some way or another.
> - Patches don't get "LOST" as you call it..
>
>Cons:
> - Can't think of any?
>  
>

Cons:

     - No Programmers and CVS users actually test the RC branch, and
keep plunking away at the trunk.
     - Programmers continue to concentrate on adding unimplemented
features instead of fixing existing bugs, since there's no active
            pushback on new features.

-J


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Vitaliy Margolen-2
In reply to this post by Molle Bestefich
Friday, October 14, 2005, 8:29:19 AM, Molle Bestefich wrote:
> Vitaliy Margolen wrote:
>> > You're rejecting a perfectly fine patch to Wine, because
>> > it's the wrong season of the year to send good patches?
>> I have no power to accept nor reject path. All I'm trying to say, is that right
>> now (Oct 14 2005) Wine is in a "code freeze" (see announcement about that few
>> weeks ago). That announcement stated that only "small bug fixes" or other well
>> warranted "small changes" will go in until after Wine 0.9 is out. And they will
>> probably get lost and will have to be resent.


>>
>> Don't get me wrong here - I am excited as you are about some one working on
>> dsound. It's just a wrong time to send this huge patches in.
>>
>> Also if you haven't looked, there are lots of open bugs in bugzilla that sooner
>> or later have to be fixed.

> Ok, I did misunderstand a bit, but also you didn't answer my main question.
> I'll just ask it again, hope it's ok:

> Why not do this:
>   Accept the patches into trunk, and do the "code freeze" in a branch.

> Pros:
>  - Developers of patches will not get pissed (ahem) for their stuff
> not getting in.
>  - Development doesn't stop just every time a release is coming up.
>  - Developers can actively select whether they'd like to help with the
> release (switch to '0.9-rc' branch) or do a little more crazy stuff
> (switch to trunk).
>  - Only sane patches get accepted to the RC by picking and merging
> those that are approved some way or another.
>  - Patches don't get "LOST" as you call it..

> Cons:
>  - Can't think of any?

Again that's not in my power to decide. But I would say - not a good time to
branch Wine. It's not stable enough to have "stable" and "development" branches.
All fixes are important. And lots of fixes are additional features. It's
something different from the rest of the projects. Wine has a some-what cleat
target of where it needs to be and what it have to do. Given that target keeps
moving all different directions and it's hard to hit it all the time ;)

Vitaliy







Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Molle Bestefich
In reply to this post by Molle Bestefich
> > Why not do this:
> >   Accept the patches into trunk, and do the "code freeze" in a branch.
> > Pros:
> >  - Developers of patches will not get pissed (ahem) for their stuff not getting in.
>
> In the open source world, anyone submitting
> a patch has to count on patiently resubmitting it
> a few times until the maintainer is ready for it.

That's a piece of monkey work right there that everybody would be
freed from, isn't it?

> Wine is no different that gcc or the linux kernel
> in this regard.

Who says that they're doing things efficiently?

> Any developer who gets upset at a patch not
> getting in during a code slush needs to chill out.

I'd say that any developer that gets upset because things are horribly
inefficient is in his good right :-)..... *expecting a slam dunk on
the head*

> >  - Development doesn't stop just every time a release is coming up.
>
> You're wrong to say that development stops during
> a code slush.  It doesn't -

Right, but there's absolutely no guarantee that those patches will
ever come back.

Developers might
 - forget about it because they've found another way which doesn't
require their fix or enhanced functionality
 - crash on a tropical island with a lot of girls, but unfortunately no internet
 - go on extended vacation, in which case it's just an unwanted delay
in Wine's progress
 - have a thousand other reasons to not care anymore (that's not
necessarily because they're angry).

> the developers keep improving their new
> feature while waiting for the slush to be over.

Yes.  But if their patches were actually *applied*, other developers
could test their changes and everything would speed up a great deal,
in theory at least.

> > - Developers can actively select whether they'd like to help with the
> > release (switch to '0.9-rc' branch) or do a little more crazy stuff
> > (switch to trunk).
>
> They can already do that; just apply the patches you're interested in.

More monkey work for the individual developer?

> >  - Only sane patches get accepted to the RC by picking and merging
> > those that are approved some way or another.
>
> Feel free to maintain an alternate tree which QA's proposed
> patches not yet in the main tree.  There are several folks who
> do this for the linux kernel.

Fair 'nuff.  Point taken.

> > - Patches don't get "LOST" as you call it..
>
> Again, the only reason a patch might get lost is because
> the author of the patch didn't follow protocol, and retransmit
> his patch periodically.

That does not make it less of a problem for Wine.
The patch would still be lost, no?

> Molle, you seem to want to fix a lot of 'process' things
> in wine that aren't broken.

I never said broken!
I'm saying that from a newcomers fantastically objective POV, there
might be a more efficient way than what everybody here's used to.  And
I do appreciate that you take time to tell me why I'm wrong.  Thanks!

> How about focusing on
> actually fixing bugs, instead of telling us how to work?

Nah, less fun.

Just kidding!

I know that the new guy who spews fancy ideas right and left which
requires the old guys to change some part of how they work is not
welcome.  I do apologize for being such a PITA for you guys.

I hope on the other hand that, IF it's not just me that doesn't
understand a perfectly good process, but there's actual room for
improvement, that you'll take some of the ideas seriously.

And I *AM* trying to chip in, I'm *not* spending all my Wine time
complaining.  Hope you don't think that I do.  I really don't!

But I have a full time job and a very large todo list.  I can't afford
to spend all my time on Wine.  Nothing really goes as fast as I'd
like.


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Andreas Mohr-2
In reply to this post by Vitaliy Margolen-2
Hi,

On Fri, Oct 14, 2005 at 08:51:06AM -0600, Vitaliy Margolen wrote:
> Again that's not in my power to decide. But I would say - not a good time to
> branch Wine. It's not stable enough to have "stable" and "development" branches.
> All fixes are important. And lots of fixes are additional features. It's
> something different from the rest of the projects. Wine has a some-what cleat
> target of where it needs to be and what it have to do. Given that target keeps
> moving all different directions and it's hard to hit it all the time ;)
>
> Vitaliy

Exactly. That's the very special case that Wine has - it is a rather
incomplete clone of the original, as such there will *always* be problems
with the code base, no matter how far we get.
I.e. it's not simply a matter of disallowing further enhancement work
that currently doesn't *need* to be available of some OSS project to reach
a certain development state required for the current release.
In Wine's case, that enhancement usually *is* needed since Windows
provides it and programs *expect* it.

That's why I think that it's not a good idea to boldly reject any and all
enhancing patches during that period. Instead, it should simply be made clear
that it's not the best thing to spend your development time on currently,
and that the preferred way is to do bug database work or program testing.

I.e. *prefer* this direction, not make it exclusive.
This could also be done by telling a developer "please no more enhancements
now" after he has done one patch too many within our "code freeze" period...
(i.e. allow a certain amount of enhancements within this time as long as
many other people are actively doing bug-fixing only)

Andreas Mohr


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Francois Gouget-2
In reply to this post by Molle Bestefich
On Fri, 14 Oct 2005, Molle Bestefich wrote:
[...]
> Ok, maybe there's one.  You need a release manager to pick which
> patches gets in the RC / release.
>
> But there must be a million ways of doing that automatically, besides
> from having an actual release manager.  Script your way out of it.
> Automatically merge patches with 'bugfix' or 'Release-Ok' in commit
> text.  Automatically merge patches < 100 lines long.  Hohum.
> Whatever.  I can think of more, I'm sure you can too.

Ok, so all this amounts to committing patches to a stable branch without
review while the branches to the unstable tip would still be reviewed
and subject to the approval of Alexandre. Why does this sound
contradictory???

I you want a stable branch you need a release manager/committee, you
cannot automate that part.

--
Francois Gouget         [hidden email]        http://fgouget.free.fr/
                       Computers are like airconditioners
                 They stop working properly if you open WINDOWS


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Marcus Meissner-4
In reply to this post by Molle Bestefich
[I can the rest ... there is just one real point I need to make here.]

> I'm saying that from a newcomers fantastically objective POV, there
> might be a more efficient way than what everybody here's used to.  And
> I do appreciate that you take time to tell me why I'm wrong.  Thanks!

We work this way for quite some time and the speed of development was
only hindered by the number of developers involved and patches submitted
up to now.

It was never hindered by the number of patches applied.
 
Ciao, Marcus


Reply | Threaded
Open this post in threaded view
|

Re: [DSOUND] add DirectSoundFullDuplex support

Detlef Riekenberg
In reply to this post by Molle Bestefich
Am Freitag, den 14.10.2005, 16:29 +0200 schrieb Molle Bestefich:

> Why not do this:
>   Accept the patches into trunk, and do the "code freeze" in a branch.
>
> Cons:
>  - Can't think of any?

Most Developer are doing the same as before: Working on there Patches.
The Code-Freeze and the Stabilisation-Affect are going to "no-op".
Review the Patches most done twice.

I'm waiting for some Patches to come into cvs, but we have to respect
the code-freeze.



--
By By ...
      ... Detlef



Reply | Threaded
Open this post in threaded view
|

Warblade startup error [bug 3875]

sebastien.fievet
In reply to this post by Vitaliy Margolen-2
Hi Vitaliy,

The message error i gave in the bug report is actually all what Wine gives me...
I can provided you with a detailed trace, but i don't know what switches to use.

Can you please tell me what's necessary for you to investigate, and i'll do my
best.

Regards, Sebastien.