Hi,
I wanted to let you know that our media team heard your feedback, and
that this problem should be addressed in our official release.
Thanks,
Bob
Joshua M. Clulow wrote:
William Yang wrote:
I am running SRS 4.1 beta on S10u5 and also see this
problem...initially I thought it might have just been XMMS, but you
are right as it is the same version that I have running on SRS 4.0 on
S10u5 without this problem. It does go away if I pick ESD plugin. I
noticed that the timer also gets funky with streams. What I see with
local audio files is that the timer is counting play time from the
time XMMS was launched.
*From:* Joshua Clulow <mailto:[EMAIL PROTECTED]>
I'm running the new SRS 4.1 beta bits on SXCE (snv_87) and its all
working very well so far, except for some minor craziness with
XMMS...
When playing audio through the Solaris audio plugin (which uses
the Sun
Ray utaudio device in $AUDIODEV) XMMS seems unable to keep track of
what
point in the audio file it's up to -- either giving outrageously
high
times or not moving the bar along at all (or both). The audio
itself
plays just as well as it ever did and this copy of XMMS works
fine on
the currently GA SRS 4 (i.e. before I upgraded to the new SRS beta.)
So, in the interests of science I have introduced some debugging
output into the XMMS code to see what was going on. It turns out that
the behaviour of the utaudio device has changed and is no longer in
line with what audio(7I) describes as expected.
From audio(7I):
"The play.samples and record.samples fields are zeroed at
open() and are incremented each time a data sample is copied
to or from the associated STREAMS queue."
In other words the "samples" field in the audio_prinfo structure
"play" within the audio_info returned from an AUDIO_GETINFO ioctl on
the audio device ought to start counting at 0 every time you open()
the audio device in question. The utaudio device certainly used to
work this way before the latest beta of the Sun Ray software, but this
behaviour no longer seems to apply.
XMMS close()s the device at the end of each song and then open()s it
again for a new song, expecting that play.samples will return to 0
every time it does so. I can fix the "broken" XMMS behaviour by
storing the current value of play.samples when the device is open()ed
and using it as an offset when calculating playback progress -- but I
don't think the software should have to compensate for this behaviour,
given the specification in the manpage.
While I can work around the problem in XMMS, I don't know what other
applications (if any!) depend on this particular behaviour and may
break. A potential workaround for XMMS is attached as a patch in case
anybody wants it -- it works for me, any feedback would be appreciated.
I tried sending some feedback to [EMAIL PROTECTED] a while ago
(about this and other issues) but I've not received a reply so I'm
just posting my findings/fixes here for the moment.
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
