Re: audio/sound control ?
I am currently developing for the Windows OS but I am looking for a cross platform solution which would allow a user of a XUL application the ability to a) adjust the system volume control (speakers/headphones) b) turn on/off the internal built-in microphone (if one exists) c) turn on/off an internal built-in camera (if one exists) d) turn on/off an external web camera by name (if one exists) e) turn on/off an external microphone by name (if one exists) I would like simplest solution possible which presumaby means accessing the standard operating system APIs. I am definitely NOT trying to distiguish between audio content from different websites at this time. I would just like some crude functionality as an interim solution Ralph Giles gi...@mozilla.com wrote in message news:mailman.342.1360081621.24419.dev-platf...@lists.mozilla.org... On 13-02-05 4:56 AM, rvj wrote: A request for a simple audio/sound interface seems to be doomed for a decade Can you be more specific? I don't know what operating system sound control is. What bug are you referring to? There's a lot of work going on right now to develop audio-related interface standards for the web. If there's a particular feature you'd like supported it's a good time to raise the issue with one of those groups. - http://www.w3.org/2011/audio/ - http://lists.w3.org/Archives/Public/public-audio/ - http://lists.w3.org/Archives/Public/public-media-capture/ - http://www.w3.org/2009/dap/ Hope that helps, Ralph ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: audio/sound control ?
... correct Michael Lefevre mjl+n...@michaellefevre.com wrote in message news:6t-dnr9sejgb5ozmnz2dnuvz_vgdn...@mozilla.org... On 05/02/2013 16:26, Ralph Giles wrote: On 13-02-05 4:56 AM, rvj wrote: A request for a simple audio/sound interface seems to be doomed for a decade Can you be more specific? I don't know what operating system sound control is. What bug are you referring to? There's a lot of work going on right now to develop audio-related interface standards for the web. If there's a particular feature you'd like supported it's a good time to raise the issue with one of those groups. - http://www.w3.org/2011/audio/ - http://lists.w3.org/Archives/Public/public-audio/ - http://lists.w3.org/Archives/Public/public-media-capture/ - http://www.w3.org/2009/dap/ I think what the original poster is asking for is a control in the browser to control audio from the web. Currently you either have to use the OS controls, or you have to work out which website is generating sound and use whatever controls (if they exist) on that website to turn it off. There are a number of bugs on this - https://bugzilla.mozilla.org/show_bug.cgi?id=24418 was recently closed and then reopened as a meta bug. (And, one of the connected bugs points out that this control is required by http://www.w3.org/TR/2002/REC-UAAG10-20021217/ - having just looked that up, I see that the requirement is still there in the current draft of UAAG 2.0...) Michael ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How does one debug uninitialized value usage from JavaScript (TB) ?
(2013/02/01 11:47), ISHIKAWA, Chiaki wrote:
(2013/02/01 11:34), Joshua Cranmer wrote:
On 1/31/2013 8:26 PM, ISHIKAWA, Chiaki wrote:
(2013/02/01 1:48), Joshua Cranmer wrote:
On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote:
Sorry, it may not have been ldap code (my memory is now hazy).
But please take a look at this code. I am using comm-central code
for development/debugging TB.
https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53
This is NSS code, which is a separate codebase included in mozilla-central and
updated periodically.
Judging from the context, this is someone using the low 32 bits as a hash key;
since it's a hashtable, I'm going to
assume that it's expected to have some amount of collisions, so the conversion
of a possibly-64-bit pointer to a 32-bit
value is safe here.
Yes, I was also expecting to see the collision resolution.
But, if my reading was correct, in one place, I thought the
equality of the hash value was deemed instantly to be the equality of the
object.
(That is why I thought something was fishy, and I assume that the coder
thought it would work only under in 32bit address space. Thus the check for
32bit
address space.)
I should have raised the flag then and there. But I went on other things, and
later when I learned the availability of 64bit version of TB, I was surprised.
It could be that my reading of equality check may have been incorrect.
Anyway, I assume that the code would bomb out by PR_ASSERT() if incorrect usage
of this funciton in 64 bit address space is encountered at run time, and
assuming that it has not happened to anybody (?), then probably
this part of the code base is not used in production TB.
That assert says that sizeof(PLHashNumber) == sizeof(PRUint32). Which is always
true thanks to
https://mxr.mozilla.org/comm-central/source/mozilla/nsprpub/lib/ds/plhash.h#18.
Hmm. I will re-read this and make sure if I understand this correctly.
TIA
(This is lengthy. Sorry about it.)
Hi,
I am still looking at the 64 bit cleanness issue of TB.
Setting the hash table issue aside (I can't still find
where the smoking gun is: it should be searchable using
the compiler warnings which initially led me to the place),
I am testing the local build of
TB under 64 bit linux using make mozmill test suite.
The result is not very promizing.
1. make mozmill seems to get hung occasionally. This never happened
under 32-bit linux. It could be related to available memory issue,
but I am not so sure. It seems that 64 bit may have uncovered
some hidden issues in TB itself and make mozmill test harness also.
2. In the session log under 64-bit linux, there are error messages
(ASSERTIONS and ERROR messages) that I have NOT noticed in the
session log of make mozmill under 32-bit linux at all (for the last
few months).
These ASSERTIONS and ERROR messages only seen in 64-bit build
are very troubling, especially the failure of iconv routine in particular.
(Not sure if this is particularly observed under Debign GNU/Linux 64-bit and not
under other linux 64-bit OS distribution.)
In one session log of make mozmill of 64 bit TB, I counted 15 repetitions of
###!!! ASSERTION: iconv failed: 'Error', file
/home/ishikawa/TB-NEW/TB-3HG/new-src/mozilla/xpcom/io/nsNativeCharsetUtils.cpp, line 541
that I didn't see in 32 bit session log at all(!).
Given that mail is about exchanging text, failure of iconv() sounds ominious.
So I inserted dump probes into the problematic source file, and found
that iconv seems to return an error value. I also called abort()
when the error is observed so that I can trace the stack using gdb.
I have found that
make mozmill test suite allows the connection to the aborted TB image for 300
seconds before moving to the next test target. During that 300 seconds,
I can use gdb to connect to the terminated process image and look at the stack,
etc..
[] Error value which seems to be returned by iconv(). (see the log in the
following)
./x86_64-linux-gnu/bits/errno.h:# define EILSEQ 84 /* Illegal byte
sequence. */
It certainly looks like the value returned by failing iconv().
[] Modified xp_iconv() :
(Notice that in the error check, *outputLeft was originally
checked even if outputLeft is NULL. So I inserted
extra check in there.)
static inline size_t
xp_iconv(iconv_t converter,
const char **input,
size_t *inputLeft,
char **output,
size_t *outputLeft)
{
size_t res, outputAvail = outputLeft ? *outputLeft : 0;
res = iconv(converter, ICONV_INPUT(input), inputLeft, output, outputLeft);
if (res == (size_t) -1) {
// on some platforms (e.g., linux) iconv will fail with
// E2BIG if it cannot convert _all_ of its input. it'll
// still adjust all of the in/out params correctly, so we
// can ignore this error. the assumption is that we will
// be called again to complete the conversion.
#if DEBUG
Re: The future of PGO on Windows
On Mon, Feb 4, 2013 at 11:23 PM, Asa Dotzler a...@mozilla.com wrote: On 2/4/2013 6:59 PM, Dave Mandelin wrote: I was talking to Taras and Naveed about this today, and what also came up was: 4. Do the work to make 64-bit JS jit perf as good as 32-bit JS jit perf, and then switch to x64 builds for Windows. There are of course many issues involved with such a switch, (These numbers are somewhat crude. I don't have excel on this machine to do precise math from our blocklist data. Given my somewhat dated info on the Windows 32 vs 64 bit breakdown that level of precision isn't really warranted.) Approximately 35% of our installs are on Windows XP. Microsoft has said that less than 1% of XP installs are 64-bit. About 7% of our users are on Vista. Microsoft said Vista's 64-bit percentage is about 11%. Just over 50% of our Windows users are on Windows 7. Microsoft has said Windows 7 installs are about 50% 32-bit and 50% 64-bit. That puts 32-bit Windows Firefox users at around 65% of our total Windows user base. With nearly two thirds of our Windows users on 32-bit Windows versions, we can't simply switch to x64 builds for Windows can we? Definitely not. Thanks for reminding me. I guess there is still an option of trying to do PGO on 64-bit builds only (which apparently is definitely not possible for VS2010 and earlier) and letting more users pick up those benefits over time. But that's not very compelling. Dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
Dave Mandelin a écrit : Approximately 35% of our installs are on Windows XP. Microsoft has said that less than 1% of XP installs are 64-bit. About 7% of our users are on Vista. Microsoft said Vista's 64-bit percentage is about 11%. Just over 50% of our Windows users are on Windows 7. Microsoft has said Windows 7 installs are about 50% 32-bit and 50% 64-bit. Seems to approximatively match generic deployment numbers : http://en.wikipedia.org/wiki/Usage_share_of_operating_systems [...] I guess there is still an option of trying to do PGO on 64-bit builds only (which apparently is definitely not possible for VS2010 and earlier) and letting more users pick up those benefits over time. But that's not very compelling. The start of the discussion is that PGO for 32-bit builds will be really hard to maintain soon. If doing 64-bit PGO builds is costly and impairs the ability to deliver efficient 32-bits non-PGO builds then it's not compelling. But if that's not the case, at least it's around 33% of users that would keep the PGO advantage, and more newer PC get sold (I just checked that even a $370 Dell Inspiron is today sold with Windows 8 64 bits). On W3Schools, XP usage is significantly going down : http://www.w3schools.com/browsers/browsers_os.asp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Cycle collection for workers
We're going to want to add worker bindings for canvas (both 2D and WebGL). Over time I expect we'll want worker versions of almost every popular DOM API that doesn't actually require content/layout. We need to be able to share code between worker and main-thread implementations as much as possible. Right now a major blocker for that is that main-thread DOM APIs require cycle collection and workers can't use cycle collection. So, what are the prospects for supporting cycle collection in workers? (I'm talking about independent cycle collectors for each thread, not any kind of cross-thread CC.) Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
