When playing a video in the video app, the sound can be barely be heard even with volume settings changed to higher levels



Firefox OS
5 years ago
5 years ago


(Reporter: mdaniloff, Assigned: daleharvey)


B2G C3 (12dec-1jan)
Gonk (Firefox OS)

Firefox Tracking Flags

(Not tracked)




5 years ago
User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; BRI/2; AskTbORJ/; .NET4.0C)

Steps to reproduce:

gaia build #20121128071138

1) Using the video app, the user launches the video.

Video should play back. There should be visuals with no gap. There should be 

Actual results:

When the user played launched the video, video playback occured with minimal sound heard even when on max settings

Expected results:

When the user played back the video, sound should play back at the relative sound settings that are set, minimum to maximum.
Please write more descriptive titles in the future when filing bugs. Put smoketest in the keywords flag, not the title.
blocking-basecamp: --- → ?
Component: General → Gaia::Video
Keywords: smoketest
QA Contact: mozillamarcia.knous
Summary: smoketest → When playing a video in the video app, the sound can be barely be heard even with volume settings changed to higher levels
Whiteboard: DUPEME
Assignee: nobody → dale
BB+, P2 - severe usability issue
blocking-basecamp: ? → +
Priority: -- → P2
Which video were you looking at?  Can you confirm that the video has a decent volume by running the same video on a desktop machine?
P2 - don't think this a smoketest blocker, unless our smoketests this week start showing this a bit more often.
Keywords: smoketest

Comment 5

5 years ago
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
WFM. Alive, which mozAudioChannel should the <video> in Video app set to? Is the current code (not set to anything) correct?
Flags: needinfo?(alive)
content because it needs to join the audio competing policy.
Flags: needinfo?(alive)
The sound in general on the unagi phone I have is very low all around. I like it LOUD, and if I play video or music I want to be able to hear it through the speaker. Also the notification of an SMS has to be loud enough to wake me (as that's how people page me).
Blocks: 822195


5 years ago
Ever confirmed: true
No longer blocks: 822195

Comment 9

5 years ago
Music is slightly louder than Video but not by much. Unless there is another way to trigger this bug that sounds significantly different I think this is just down to the speakers not being particularly loud, when plugged into external speakers the sound is at expected volumes and at all times it is respecting the volume control

Not sure what I can do about this.

Comment 10

5 years ago
If this issue is only with recorded videos, then a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=816342 ?


5 years ago
Keywords: qawanted
I agree with Sheeri in Comment 8, and I filed Bug 821416 to cover the overall issue of audio performance on the phone. 

Matt needs to clarify whether he was talking about the overall volume being too soft when playing videos from the video app, or whether this bug is about not respecting the volume controls settings.
Without more detail or a sample video, it seems like this should be duped to one of the above issues. I'm guessing 816342.
blocking-basecamp: + → ---
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 816432
Duplicate of bug: 816342

Comment 14

5 years ago
since its a dupe
remove qawanted
Keywords: qawanted
Whiteboard: DUPEME


5 years ago
OS: All → Gonk (Firefox OS)
Hardware: All → ARM

Comment 15

5 years ago
tested on unagi build #20130121070201

the sound has been enhanced in the higher volume levels..25%

Comment 16

5 years ago
Unagi build 20130211070202 with Dec 5th Kernel

Verified as duplicate of bug 816342
You need to log in before you can comment on or make changes to this bug.