5월 2주차 1차 통합과정

[Jangsuyoung]

1. SBC - Android 간 사운드 테스트
2. 접속자 수 N 테스트

[Jangsuyoung]

1. UDP 통신 UDP Broadcasting을 이용하여 구현 자신의 하위 네트워크에 있는 호스트에게 데이터를 뿌려준다. 싱크는 잘 맞았으나 네트워크 망에 영향을 많이 받는다. 다른 사용자가 망에 접근을 하거나 검색하게 되면(scanning) 데이터 전송이 원활하게 되지 않는다.

scanning을 수정하는 방법이 애플리케이션단에서 할 수 있는 일이 아니였기 때문에 TCP 방법으로 수정구현 예정

세부적 원인 확인 => 1 .와이어샤크를 통해 패킷을 잡아서 보니 각각의 기기가 검색 시 패킷을 전송한다. server에서 보내는 패킷과 네트워크 검색과 연결을 위해 패킷을 보내는 다른 휴대폰 간의 간섭으로 인해 패킷이 손실된다.

2. 안드로이드 로그를 통해 받은 패킷 확인 아무런 간섭이 없을 때에는 거의 로그가 한페이지씩 채워졌는데 간섭이 생기자 반페이지 정도만 채워지는 시각적으로 보이는 패킷량 감소를 볼 수 있었다.

[Jangsuyoung]

1. Frame과 Buf의 차이 SBC에서 frame 변수를 정할 때 sampling rate와 frame이 나누어 떨어져야 정확한 소리를 얻을 수 있고 frame 크기가 작을 수록 음성 Sink가 맞게 된다. (단, UDP 에서는 보내는 버퍼와 받는 버퍼의 크기가 동일해야 한다. TCP는 네트워크 상에서 자동으로 패킷을 쪼개서 재조합하지만 UDP는 그런 역할이 없어 크기 그대로 전송을 한다. )

안드로이드 buffer크기가 작아야 소리를 빠르게 감상할 수 있고 frame과 안드로이드 buffer 크기는 나누어 떨어져야 한다. 그렇지 않으면 zero - padding이 되기 때문에 뚜뚜뚜 소리같은 소리가 나거나 받지 못한 부분은 자동으로 음이 끈키는 현상이 발생

AudioTrack write를 사용할때 buffer 사이즈가 작을때는 2의 power승으로 해야 했다. 그렇지 않으면 음이 중간중간 끈키는 현상 발생 따라서 2의 power승으로 만들어서 해결

[Jangsuyoung]

1. 서버는 client accept하는 main process , 음성 추출 thread, 각 client와 서버 소켓에 해당하는 thread로 구성 이떄 TCP가 전송을 할 때, 이미 보냈던 데이터를 다시보내는 현상 발생 => 해결 위해 flag를 두었다. 단일 통신에서는 flag변수하나로 가능했지만 multithread간에 flag를 두는데 어려움.

TCP 로 구현을 하면 N의 수가 증가할수록 즉 Client가 많이 붙을 수록 딜레이가 발생하는 것을 확인 !!

따라서 두가지 해결책을 모색

1. thread 갯수를 최소화
2. Client는 각각의 쓰레드이고 signaling을 통해 signal을 받으면 send하기

[Jangsuyoung]

1. thread간 signal 통신을 통해서 음성을 뽑으면 나머지 전송 thread에게 signal을 전송시킨다. 이 signal을 받으면 각 thread는 자신의 client에게 음성을 보내준다. 하지만, thread 간의 delay 발생...
2. thread를 최소화 하기위해 accept하는 main process, 음성 추출 thread, 사용자를 관리하여 보내는 thread 세 개로 변경. accept시 client의 socket number를 전역변수 배열로 관리. 음성을 추출하여 buffer가 업데이트 될 때, 사용자 관리 thread에게 signal을 보내고 모든 client 에게 데이터를 보내준다.

-> 현재 N이 6명일때까지 테스트 확인 !! 아주 약간의 딜레이가 있지만 그정도는 들을만한 정도 음성 압축과 음성 보간을 통해 해결할 예정

[lilly2232]

중간 발표 보고

1. 잡음 제거 처리 -> 화이트 노이즈 잡기
2. UI 수정 하기
3. 외부망 이용하여 네트워크 사용할 수 있도록 하기