잘못 기억한 게 아니라, 그냥 옛날 방식에 익숙한 거예요 
이 기능은 Mumble 자체가 10년 넘게 된 시점에, Mumble 1.3에서 겨우 10년 전에 추가되었습니다.
오래전부터 Mumble에 대한 가장 큰 불만 사항 중 하나였습니다.
5개의 좋아요
방금 이것을 직접 사용해 봤는데 정말 멋집니다! 초기 피드백을 좀 남겨보려 합니다.
- 화면 공유와 음성 볼륨:
직접 시도해 봤는데, 다른 참가자의 화면 공유 볼륨이 음성 볼륨과 별도로 표시되지 않습니다. 목소리와 화면 공유 오디오를 모두 포함하는 하나의 통합 슬라이더만 표시됩니다. 슬라이더를 놓쳤거나 잘못 이해한 건가요? (제 사용 사례는 게임 스트림의 볼륨을 음소거하거나 낮추면서도 상대방의 목소리는 들을 수 있도록 하는 것입니다.)
- 작은 버그: 방을 편집할 때(예: 방 이름의 첫 글자를 대문자로 변경), 다시 편집하려고 돌아왔을 때 페이지를 새로고침할 때까지 편집 옵션이 표시되지 않습니다. 편집을 적용한 후 클라이언트 UI가 제가 권한이 있음을 잊어버리는 것 같습니다.
- IP 프라이버시 팝업에 정말 감사드립니다! 이런 우려를 미리 고려해 주셔서 감사합니다
- 제 시스템에서는 마이크가 매우 작아서 많은 부스트가 필요합니다. 이것은 제 쪽의 시스템 문제이지만, Mumble(그리고 Discord도 그럴 것 같은데, 오랜만이어서 기억이 나지 않습니다)에서는 수동 이득(gain)을 많이 적용하여 이 문제를 극복할 수 있습니다. 자동 이득 옵션을 비활성화할 때, 부스트를 위한 여유 공간(headroom)이 아주 많은 수동 이득 조절기를 제공하는 것을 제안합니다. (제 일반적인 원본 배경 소음은 -48db이고, 음성은 약 -30db입니다. Audacity에서 정상 범위로 올리려면 약 20db 부스트가 필요합니다.)
- Discourse 때문은 아니지만, 모든 Linux WebRTC 화면 공유가 가진 한계와 동일합니다. 즉, Firefox에서는 오디오 화면 공유가 지원되지 않고, Chrome은 브라우저 탭 오디오 화면 공유만 지원합니다. 따라서 게임을 스트리밍하려면 브라우저 한계로 인해 Linux에서 게임 오디오를 스트리밍할 수 없습니다.
- 다른 솔루션에서 확인한 기발한 우회 방법은 OBS를 가리킬 수 있는 엔드포인트 주소를 노출하는 것이었습니다. (아마 Livekit이 이미 이것을 지원할 수도 있는데, 아직 Livekit 서버 부분을 설정하지 않아서 모르겠습니다.)
- 자막 기능에 정말 인상받았습니다! 전사(transcription) 부분은 아직 사용 사례가 없지만, 비즈니스 환경에서 메모를 작성하는 데 유용할 수 있다는 점은 분명히 알 수 있습니다.
- 현재 UI상의 어려움이 있습니다. 방문자가 채팅방에 사람이 있는지 알기 위해 아래로 스크롤해야 합니다 – 때로는 꽤 긴 거리로요. 제 설치 환경에서는 링크/카테고리/태그가 많아 한 페이지를 넘어서는 스크롤이 필요합니다. 모바일에서는 특히 더 심해서, 메뉴 바를 클릭하지 않으면 채팅 사용자 목록이 아예 표시되지 않습니다. 채팅이 활성화될 때 우측 상단에 어떤 종류의 버튼을 두는 것을 제안합니다. (예: mumble). 채팅방에 **(1)**명 이상 있다는 것을 보는 것은 누군가 채팅에 참여하길 원한다는 제 주요 신호입니다!
어쨌든, 정말 좋은 작업입니다 – 이것은 Discourse에 있어 큰 전진이며, 매우 기대됩니다! 
6개의 좋아요
많은 훌륭한 피드백을 주셨는데, 그중 한 가지를 강조하고 싶습니다.
이것이 지금까지 제 주요 과제였으며, 브라우저는 하드웨어 인코딩을 지원하지 않기 때문에 7680x2160@240Hz 게임 세션을 브라우저로 스트리밍하는 것은 불가능하다는 점에서 플랫폼을 초월하는 문제입니다.
따라서 이러한 통합을 더 잘 처리할 수 있도록, 전역 PTT와 같은 기능을 네이티브 데스크톱 앱으로 처리하는 방안을 검토하고 있습니다.
6개의 좋아요
감사합니다. 네이티브 데스크톱 앱은 흥미롭지만, 기존 오픈 스트리밍 표준도 지원해 주시면 좋겠습니다. 적어도 제 친구들 사이에서는 이미 OBS를 설치해 두고 있고, 신뢰하며, 어디로 스트리밍을 보내야 하는지도 잘 알고 있으니까요. (솔직히 말하면, 이는 비기술적인 사용자들보다 게이머들 사이에서 더 흔한 경우입니다.)
1개의 좋아요
어떤 면에서는 동의합니다. 즉, 줌(Zoom)은 아니라는 뜻이죠. 하지만 저는 일부러 반대의견을 내도 된다고 생각합니다. 왜냐하면 다행히 OBS는 많은 분야에서 표준으로 사용되고 있기 때문입니다!
1개의 좋아요
오늘 리빌드 과정에서 작은 문제가 발생했는데, 그 이유는 이전에 플러그인 이름을 'Resenha’로 테스트했기 때문이에요. 참고로 이름을 'Voice’로 바꿨을 때 좀 속상했어요.
이 방법으로 제 문제를 해결했습니다:
2개의 좋아요
이제 플러그인 자체에 대해 이야기하자면, 거의 2주 동안 300개 이상의 커밋을 포함해 재빌드한 후 이런 현상을 알게 되었습니다. 제 착각일 수도 있지만, 제 인스턴스에서 음성 기능을 테스트했을 때 토글이 '오프라인’으로 설정되어 있었음에도 #quem-está-online 채널에 표시되었습니다. 이것이 정상적인 동작인가요?
이 문제는 곧 수정될 예정입니다: FIX: Do not overwrite permissions after editing - Pull Request #43496 - discourse/discourse - GitHub
3개의 좋아요
호스팅된 페이지의 about > site activity 섹션에 (예를 들어) 지난 7일간의 음성 채팅 5회를 표시하는 것이 가능한가요? 또는 적절한 표현이 있다면 그것도 괜찮습니다.
새로운 멤버들이 가입하도록 돕기 위해 최대한 많은 활동 내역을 보여주고 싶습니다.
4개의 좋아요
개별 사용자 대신 그룹을 음성 룸에 초대할 수 있을까요? 해당 그룹에 여전히 속해 있는 사람을 제외해야 하는 경우 멤버 페이지가 복잡해질 수 있다는 점은 알고 있습니다.
현재 진행 중인 고객 대상 프로젝트 몇 가지에 이 기능을 적용할 계획인데, 각기 다른 구성원이 포함된 17개 그룹이 있습니다. 
네, 이것이 기본적으로 이렇게 작동하는 이유입니다.
이 전체 기능을 해당 17개 그룹의 멤버로 제한하고 싶다면 사이트 설정을 통해 가능합니다. 하지만 일회성 초대 링크는 사용자별로 발급되며(스팸 증폭이 너무 쉬움), 방 멤버십 자체도 사용자별로 관리됩니다(그룹과 동기화하는 것은 향후 개선 사항이 될 것입니다).
4개의 좋아요
전혀 동의합니다. API를 통해서도 이걸 할 수 있는 방법이 없는 것 같습니다 
초대 링크 방식에서 제가 놓치고 있는 부분이 있을까요? 승인된 그룹에 포함된 테스트 계정에 링크를 공유했는데, 테스트 유저로 링크를 클릭하면 Oops! That page doesn’t exist or is private 오류가 발생합니다.
업데이트: 아예 그 유저를 초대해서 사이드바에서 음성 채널이 보인다고 해도, 링크를 클릭하면 그 Oops 페이지로 이동합니다.
1개의 좋아요
채널이 비공개 카테고리와 연결된 경우, 해당 채팅 채널에 사람을 추가하고 제거하는 일부 로직은 이미 처리하고 있습니다.
Falco, 음성 채널을 채팅 채널과 연결하는 방법이 이미 있는지 기억이 나지 않습니다. 과거에 DM(대화를)에 대해 그 부분을 논의했던 것 같습니다. 하지만 이번에는 그 접근 방식이 도움이 될 수 있습니다.
대안으로, 채팅 채널에서 수행하는 방식을 그대로 적용하여 카테고리를 액세스 제어 계층으로 사용할 수 있습니다(다만, 그 인irection 계층을 제거하고 채널 수준에서 직접 액세스를 설정할 수 있도록 해야 한다는 논의가 자주 이루어졌다는 점은 알고 있습니다).
- 비공개 카테고리 설정
- 해당 카테고리를 위한 채팅 채널 생성
- 해당 채팅 채널에서 음성 활성화(또는 해당 카테고리를 위한 음성 채널도 생성)
전체 기능을 특정 그룹 집합으로 제한하고 싶다면, 여전히 사이트 설정을 통해 관리해야 한다고 생각합니다. 워크플로가 해당 부분의 일정 수준의 자동화 또는 일관성 검사를 관리하는 데 도움이 될 수 있습니다.
@martin 이 내용은 현재 작업 중인 일반적인 액세스 제어 관련 작업과 일부 겹칠 수 있습니다.
@awesomerobot과 곧 그 부분에 대해 더 폭넓게 추진하기 위해 이야기를 나누어 보면 좋겠습니다. 그러면 앱 전체에서 그 측면을 더 일관되게 적용하는 방법에 대해 생각해 볼 수 있을 것입니다.
1개의 좋아요
이상하네요, 그 테스트 사용자들은 뭔가 이상한가요, 접근이 허용되지 않는 신뢰 수준에 있는 건가요?
네, 로드맵에 있습니다.
확실히 릴리스를 막는 장애물은 아니었고, 앱의 그 부분은 매우 복잡해서 우리의 노력이 오디오와 비디오의 핵심 기능을 제대로 잡는 데 더 잘 사용될 수 있지만, 앞으로 몇 달 안에 후속 조치를 취할 것입니다.
5개의 좋아요
dev에서 답변을 남겼는데, 기존에 복잡하게 카테고리별 상속으로 권한을 관리하던 방식보다 새로운 ACL 시스템이 이 용도에 훨씬 적합할 것 같아요
2개의 좋아요
그렇지는 않을 것 같습니다. 제 테스트 사용자를 TL3로 올렸기 때문에, 확실히 TL 제한 문제는 아닙니다. 초대 링크 자체에 문제가 있는 것 같습니다. 아래는 일반 방식으로 접근했을 때의 모습입니다(제 사용자가 접근 권한이 있든 없든 링크의 동작은 동일합니다).
불행히도, 이 그룹들은 DM(대면 메시지)을 통해서만 작동하므로, 의존할 수 있는 카테고리별 연결 관계가 없습니다.
왜 작동하지 않는지 파악할 수만 있다면, DM에서 초대 링크를 공유하는 것으로 충분할 것이라고 생각합니다.
1개의 좋아요
방 유형이 '공개’로 설정된 음성 방에 입장할 때마다 마이크가 자동으로 켜지는 것을 확인했습니다. 스피커가 스테이지 음성 방에 입장할 때도 동일한 현상이 발생합니다. 관리자가 입장 시 마이크를 자동으로 켤지 여부를 설정할 수 있도록 하는 것이 가능한지 궁금합니다.
1개의 좋아요
그렇게 하면 혼란스럽지 않을까요?
Zoom, Teams, Meet 같은 ‘업무용’ 회의 앱들은 참가자 수가 특정 임계값을 넘으면 이러한 동작을 수행합니다. 하지만 저희가 영감을 받은 TeamSpeak, Ventrillo, Mumble, Discord 등 ‘학교’ 앱들에서는 이러한 동작이 결코 존재하지 않았습니다.
저는 이 추가 단계가 이전 사례가 거의 없다고 느끼며, 초보자에게 사용자 경험(UX)을 더욱 복잡하게 만드는 추가 단계처럼 느껴집니다.
2개의 좋아요