Closed Bug 816608 Opened 12 years ago Closed 12 years ago

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

Categories

(Firefox OS Graveyard :: Gaia::Video, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 816342
B2G C3 (12dec-1jan)

People

(Reporter: mdaniloff, Assigned: daleharvey)

Details

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/5.15.9.29495; .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
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.
https://github.com/mozilla-b2g/gaia/blob/master/apps/video/js/video.js#L15
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
If this issue is only with recorded videos, then a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=816342 ?
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.
Status: NEW → RESOLVED
blocking-basecamp: + → ---
Closed: 12 years ago
Resolution: --- → DUPLICATE
since its a dupe
remove qawanted
Keywords: qawanted
Whiteboard: DUPEME
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
tested on unagi build #20130121070201

the sound has been enhanced in the higher volume levels..25%
Unagi build 20130211070202 with Dec 5th Kernel

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